RE: Performance Decrease After Moving Working Copy to Another Machine

Hello Johan,

Thank you so much for your response! It was incredibly helpful and clear.

You were correct in the fact that my "tar" command was not preserving the correct modified timestamps. It turns out that the default tar format is GNU, which only supports timestamp up to a granularity of seconds (https://bugs.launchpad.net/duplicity/+bug/696614). I added a flag "--format=posix" to get the necessary nanosecond timestamp needed for Subversion.

If it is helpful for your future reference, the linux command to get precise access + modify + change timestamps is the "stat" command.

You have been an awesome help. Thanks again!

All the best,
Brandon

-----Original Message-----
From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
Sent: Thursday, June 16, 2016 12:35 AM
To: Brandon Eusebio <beusebio_at_ghs.com>
Cc: users_at_subversion.apache.org
Subject: Re: Performance Decrease After Moving Working Copy to Another Machine

On Wed, Jun 15, 2016 at 11:36 PM, Brandon Eusebio <beusebio_at_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