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.
Michael
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