Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <5c781ac6a5dc4d639fc58f8f17b9e159@exsvr1.ghs.com>
References: <5c781ac6a5dc4d639fc58f8f17b9e159@exsvr1.ghs.com>
From: Johan Corveleyn <jcorvel@gmail.com>
Date: Thu, 16 Jun 2016 09:34:36 +0200
Message-ID: <CAB84uBUOkW48_hXEoWD3PMxBkq_VOnGSW_Gc_5umXvKVp=6O1w@mail.gmail.com>
Subject: Re: Performance Decrease After Moving Working Copy to Another Machine
To: Brandon Eusebio <beusebio@ghs.com>
Cc: "users@subversion.apache.org" <users@subversion.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Thu, 16 Jun 2016 07:35:02 -0000

On Wed, Jun 15, 2016 at 11:36 PM, Brandon Eusebio <beusebio@ghs.com> wrote:
> Hello,
>
>
>
> I am trying to move/copy a Subversion (version 1.8.10) working copy from one
> linux machine to another. From researching similar questions/answers, this
> seems possible by simply moving the entire folder (along with the .svn
> subdirectory). I have implemented a solution that performs this copy using
> tar.
>
>
>
> On source machine:
>
> `tar -cpz -f checkout_directory.tar.gz checkout_directory`
>
>
>
> On destination machine (after copy of the tarball):
>
> `tar -xpz -f checkout_directory.tar.gz`
>
>
>
> This achieves the goal of moving the working copy to the destination
> machine; however the performance of svn operations becomes drastically
> slower. For example, a `svn status` on the original machine takes < 1
> minute, but takes ~1 hour on the destination machine. The entire folder is
> ~50GB, but these timings include clearing out the linux buffers/caches and
> similar hardware/load on each machine.
>
>
>
> I can mitigate the performance hit by doing an `svn cleanup` on the
> destination machine, but this operation also takes ~1 hour. I suspect this
> updates the change times that Subversion uses to determine whether or not
> local changes have been made
> (http://svn.haxx.se/users/archive-2003-11/0595.shtml).
>

Yes, for the working copy to work optimally, the mtimes (last
modification time) of the files need to correspond exactly to the
corresponding values in the svn metadata (stored in .svn/wc.db, an
sqlite database). Running 'svn cleanup' will fix this, because it
corrects the metadata in wc.db to note the correct mtimes.

I'm not sure if your tar commands precisely preserve the mtimes of the
files (googling around for tar and mtime brings up several discussions
where "it should, but sometimes it doesn't"). And with precisely, I
mean "up to the nanosecond, exactly the same timestamp as on the
original file". Also: what sometimes happens is that there is a
difference in filesystems between source and target of the copy, so
they might have different timestamp granularity on the filesystem
level, leading to slightly different timestamps.

I would suggest you try to verify the timestamps for some files in the
source and target working copies, and their corresponding values in
wc.db:

1) Run "ls" with some option to display precise timestamps (on Solaris
you get "full-iso" time-style by running "ls -E", don't know the exact
equivalent for linux). Check this on source and target. If they are
different then there is your problem.

2) To double check, you can also see what the value in wc.db is, by
running a query with sqlite3 like this:

    sqlite3 -header -column wc.db "select local_relpath, last_mod_time
from nodes where local_relpath='path/to/file'"

You'll probably have to convert the value you get there (it will be in
milliseconds or microseconds "since epoch"), for instance use this:
http://currentmillis.com/

HTH,
-- 
Johan