subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Mikesell <>
Subject Re: Estimation of repository upgrade
Date Fri, 05 Aug 2011 18:02:09 GMT
On 8/5/2011 12:33 PM, Bob Archer wrote:
>>> Until you manually copy over the $repodir/db/uuid file, this is true.
>>> That's one of the "relevant configuraton files" I referred to.
>> So, are you saying svnsync will be faster than a dump/load?
>> I didn't know the guid was stored in a file.
>> svnsync is slower than dump/load.  I think the issue is that you can keep the
>> old repository online during the process and switch when you are ready.
>> BTW, why copy a file you are not supposed to when you could just use the
>> svnadmin setuuid command to make the Repository UUID match between
>> the two repositories?  No need to involve yourself in the internals of the
>> repository when there is a public interface to do it for you.
> Yes, that was my thought too. I will just run the dump/load during the weekend again.
Also, now that I know you can dump/load in a single step rather than to disk then load it
shouldn't be so bad.

Svnsync can be run anytime without bothering the working repo very much 
so you can have most of the contents in the new one well ahead of time 
and repeated runs pick up where it left off.  You just need to make sure 
that no commits are done while you make the final run before the cutover 
- which can be very quick.

> I do think I will plan to dump filter out all the paths with binaries and move them to
the file system only or a separate repository that can be purged periodically and then use
externals to bring them into the WC. I think some people here have mentioned a binary library
tool that rotates your binaries... or I can just add it to my nant scripts like I currently
do it with test installers.

If you come up with a good scheme for this that doesn't interfere too 
much with using externals to pull in component libraries without 
recompiling, please post it.

   Les Mikesell

View raw message