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.
