subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: svncutter can be removed
Date Wed, 03 Feb 2016 12:55:20 GMT


> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: woensdag 3 februari 2016 09:18
> To: Greg Stein <gstein@gmail.com>
> Cc: Eric Raymond <esr@thyrsus.com>; dev@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@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


Mime
View raw message