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
> have a chance to catch up?
Peter, that would be great. I'll sign you up for it in
merge-tracking.txt, and split off the JavaHL APIs for Mark and myself.
> > - 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 (range, is_revert)? I think that's a more intuitive
> API.
I was assuming that all revision ranges in the list would be either
"forward merges" or reverts. Were you think that this might be
otherwise? Do you think allowing the ability to mix these two types
of changes in a single operation is a good idea for usability? (I
haven't thought it through.)
> 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.
Sorry, I was in a hurry when I wrote this, and provided a very poor
example.
> 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.
On Tue, 03 Apr 2007, Michael Brouwer wrote:
> 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.
If we punch this functionality through to the UI of the command-line
client (and I'd rather like to), we absolutely need to support lists
for both -c and -r. In my experience, the typical use case will be -c
with a list of single revisions; however, sometime you'll want to
specify a list of ranges, which will require -r per our command-line's
UI.
Question: Will implementation of this be tough with the command-line
client's current argument handling? Or can we special-case things for
'merge'?
- application/pgp-signature attachment: stored
Received on Thu Apr 5 02:16:14 2007