"Florian Storck" <firstname.lastname@example.org> wrote on 10/24/2005 08:51:09 AM:
> I'm thinking about an upgrade to SVN 1.2.3, which needs a complete
> cycle (from 1.1.2) . Because some of our repositories are quite large,
> thinking of migrating only a part of the revision history, to increase
> and have a smaller repo again. But because the build uses the revision
> numbers of the repository for tracking, this would create rev numbers
> could collide with old ones.
> Because of that, one idea would be to add an revision offset, when load
> dumped repo in the new one. Is this a possibility in SVN ?
> The alternatives are quite quite clear like create a new minor revision
> But I would like to avoid that. Any suggestions ?
This doesn't really answer your question, but it is not true that you need
to dump/load your repository to go from 1.1.x to 1.2.x (or 1.3.x when it
You can do this if you want to switch from BDB to fsfs or vice versa. The
only other thing is that 1.2.x uses a new delta algorithm. If you
dump/load your existing revisions will be recalculated using the new
algorithm. This gives a speedup to a few operations like blame, but it
also uses approximately 10% more space.
The point being simply that you do not have to dump/load, it is your
choice and it could also be done after you have upgraded to 1.2.x.
Finally, while trimming revisions from your repository will presumably
reduce the size, I do not believe there is any reason to expect a
significant performance improvement. Obviously you have 1000 folders
under a tags folder and you cut that to 10 there will be performance
improvements in listing the contents of that folder, but a checkout from
trunk will likely take the same amount of time.
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Oct 24 15:42:53 2005