subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Harold <thomas-li...@nybeta.com>
Subject Re: Breaking up a monolothic repository
Date Tue, 10 Sep 2013 17:45:43 GMT
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.


Mime
View raw message