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

Re: svncutter can be removed

From: Greg Stein <gstein_at_gmail.com>
Date: Tue, 2 Feb 2016 19:48:53 -0600

On Tue, Feb 2, 2016 at 7:45 PM, Eric S. Raymond <esr_at_thyrsus.com> wrote:

> Greg Stein <gstein_at_gmail.com>:
> > But I'll take care of it for you, no worries. I'll rm the content, and
> > leave a README pointing to reposurgeon.
> Thanks.
> > Much appreciated for the prior work, and the heads up!
> As a matter of potential interest: I originally thought that svncutter
> would be completely obsolesced by reposurgeon. But it turns out there
> is one case where the former is still more useful. That's when you
> have a multi-project Subversion repository and want to split it up
> into components for separate conversion to git or whatever.
> Because of the difference between Subversion and DVCS branching models,
> this kind of situation is better handled by using svncutter to extract
> the components into separate dumpfiles (and then perocessing each one
> through reposugeon separately) than it would be by reading in the whole
> repo at once and doing the dissection in gitspace.

Gotcha. How is that different from "svndumpfilter include" ?

Or maybe the latter was created after you started svncutter?

That's why repocutter still exists. It's not a hugely common case, but
> it comes up often eniugh to merit some support.

We actually use it quite a bit at the ASF, when projects go from the
"mother" svn repository, to Git repositories. Git is simply unworkable at
the scale of our svn repository, so projects have to switch to one or more
Git repos when they convert.

Received on 2016-02-03 02:48:57 CET

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