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

Re: Handling multiple revision ranges in a single merge operation

From: Michael Brouwer <mb.7766_at_gmail.com>
Date: 2007-04-03 17:20:28 CEST

You should probably even allow mixing of -c and -r options. Something like

svn merge -c3 -r5:7 -c10

Could be made to work, and might be useful when specifying mixed changesets
and revision ranges. It should probably be an error if any revision is
included more than once. However that said something like:

svn merge -r3-10 -c-4 -r9:8

could be allowed as well.


On 4/3/07, Peter Lundblad <plundblad@google.com> wrote:
> Daniel Rall writes:
> > I'd like to extend the svn_client_merge_peg3() API to accept a list of
> > revision ranges to merge. As this API already been rewritten
> > internally to handle this to support Merge Tracking, we'd only be
> > exposing functionality that 'merge' is already offerring.
> >
> This sounds good! IF OK, I'd like to take that one as part of reworking
> the algorithm to avoid too many conflicts. I don't want to block things
> on it,
> but if you have other stuff, maybe you could take that first and I might
> ahve
> a chance to catch up?
> > - Should the API take two svn_opt_revision_t *'s lists, or a single
> > list composed of a data structure consisting of a start and end
> > svn_opt_revision_t * (a la svn_merge_range_t)?
> What about a list of (rnage, is_revert)? I think that's a more intuitive
> API.
> Giovanni Bajo writes:
> > > - Should 'svn merge -rN URL [WC_PATH]' also support this?
> > > Example: svn merge -r3,5-7,10 $URL
> >
> > Wouldn't it better to use -c for this? -rN:M already has a meaning of
> svn
> > merge, so adding -rN,M and -rN-M to it looks like a bit of a confusion.
> >
> Agreed. We could extend -r to support more than one revisoion range:
> -r1:2,4:3, meaning -c2,-4,
> but I think -c is more intuitive.
> Thanks,
> //Peter
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 3 17:20:45 2007

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.