[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: Bert Huijben <bert_at_qqmail.nl>
Date: Wed, 3 Feb 2016 13:55:20 +0100

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: woensdag 3 februari 2016 09:18
> To: Greg Stein <gstein_at_gmail.com>
> Cc: Eric Raymond <esr_at_thyrsus.com>; dev_at_subversion.apache.org
> Subject: Re: svncutter can be removed
>
> On Tue, Feb 02, 2016 at 07:48:53PM -0600, Greg Stein wrote:
> > On Tue, Feb 2, 2016 at 7:45 PM, Eric S. Raymond <esr_at_thyrsus.com> wrote:
> > > 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" ?
>
> I would guess it handles missing copyfrom sources more intelligently
> than "svndumpfilter include", which simply errors out when it hits
> that case (svndumpfilter: E200003: Invalid copy source path '/foo').

In my experience using svndumpfilter without --drop-*, but without
--renumber-revs is the most likely cause of these problems. Forgetting to
add that flag just creates invalid dumpfiles, so I don't think we should
have allowed that scenario. (Where is my time machine?)

BTW: svndumpfilter existed since Subversion 1.0, so it certainly predates
2009. Not sure about when its specific features were introduced though.

        Bert
Received on 2016-02-03 13:55:31 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.