[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: Peter Lundblad <plundblad_at_google.com>
Date: 2007-04-03 11:02:22 CEST

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

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.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 3 11:02:52 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.