[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Best practices on how to reorganize repository

From: Talden <talden_at_gmail.com>
Date: Mon, 31 Mar 2008 00:04:56 +1300

On Sat, Mar 29, 2008 at 7:08 AM, Dieter Oberkofler
<d.1234567890_at_qualiant.at> wrote:
> 1) It is quite a large project by itself (the trunk has about 50000 files)
> 2) We have converted almost 15 years of history into SVN (about 30000
> revisions)
> 3) We also have quite some binary data in the repository (documentation,
> tools, images, etc)
> 4) A very large number of tags and branches have been used
> 5) A large number of quite large vendors branches are part of the repository

Be aware that the supported mechanism of "dump -> filter -> load" does
not does the heavy lifting of tracing where a filtered path has been
copied to. If path X has been copied into 5 branches and 2 tags and
you only filter X, two tags and two branches then the 3 remaining
branches which did have cheap copies are now 3 full-text revisions --
that is, you can obliterate and end up with a larger repository than
you started with.

There are other, more obscure ways in which a repository could become
larger - the reload with obliterated content could select different
revisions to use the 'skip' part of the skip-delta model and could
result in small diff revisions becoming full-text revisions.

Surgery like this on a repository is a serious under-taking and may
not yield the space savings that would seem apparent at first glance -
given you can produce quite misleading history in revisions with
obliterated content you may want to reconsider. That said, it
certainly has its place.

Remember to reload into a new repo with the same ID) - that way, if
the revision numbers aren't changed and no users have any checkouts
with paths that were obliterated, they may be able to continue to use
their working-copy. Most often though users will need to checkout
again - this dump-filter-reload mechanism is a destructive and
untracked operation.

To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-30 13:05:21 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.