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
lesmikes...@gmail.com
