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

Re: Breaking up a monolothic repository

From: Thomas Harold <thomas-lists_at_nybeta.com>
Date: Tue, 10 Sep 2013 13:45:43 -0400

On 9/10/2013 7:22 AM, Nico Kadel-Garcia wrote:
> But keeping thousands of empty commits in a project they're not relevant
> to is confusing and wasteful. The repository and repository URL's for
> the old project should be preserved, if possible, locked down and
> read-only, precisely for this kind of change history. But since the
> repository is being completely refactored *anyway*, it's a great
> opportunity to discard debris.

When we moved from a monolithic repository to per-client repositories a
few years ago, we went ahead and:

- Rebased the paths up one or two levels (old system was something like
"monolithicrepo/[a-z]/[client directories]/[job directory]") so that the
urls were now "clientrepo/[job directory]". That was a tricky thing to
do and we had to 'sed' the output of the dump filter before importing it
back.

It broke a few things, such as svn:externals which were not
relative-pathed, but was worth it in the long run so that our URLs got
shorter.

- Made sure that the new repos all had unique UUIDs.

- Renumbered all of the resulting revisions as we loaded things back in.
  But we didn't have to deal with any bug tracking systems that referred
to a specific revision. And having lower revision numbers was
preferred, along with dropping revisions that referred to other projects.

> Even if the history is considered sacrosanct (and this is often a
> theological policy, not an engineering one!), an opportunity to reduce
> the size of each repository by discarding deadwood at switchover time
> should be taken seriously.

Less of an issue now that svn 1.8 has revprop packing (plus the rev
packing from 1.6). That deadwood takes up a lot less space in terms of
the number of files in the file system.

And the fact that svnadmin hotcopy is now incremental in 1.8 also makes
it less of an issue. Having a few thousand (tens of thousands)
revisions in a repository is no longer a big bottleneck during the
hotcopy process like it was before.

Our backup system is also a lot happier with fewer files to backup.
Received on 2013-09-10 19:46:22 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.