> Am 10.09.2013 19:45, schrieb Thomas Harold:
>
> > 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.
>
> I'm now facing the same problem. My users want the rebasing, but during the
> dump/load instead of after the fact (apparently, it causes issues with their
> environment when they need to go back to an earlier revision to reproduce
> something). They also want to keep the empty revisions (for references from
> the issue tracker).
Wouldn't it be much simpler to keep the current repository as a read only archives and move the HEAD of each project into its own repo?
> I haven't tried it with svnadmin dump followed by svndumpfilter (I don't think it
> has that capability).
>
> I've tried svnrdump (from svn 1.7), it resulted in either a new repository with
> the full path included (rdump/load all revs) or an interesting failure mode with
> a missing node during a copy operation when rdump -r
> <revision_after_path>:HEAD was used
>
> I've also tried using svnsync, but that also results in the full path included, no
> rebasing.
>
> How did you do it? Also, am I missing something that has been included in a
> current svn version?
>
> Cheers,
>
> Ulli
Received on 2013-10-02 19:01:26 CEST