You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2007/09/19 18:19:49 UTC
New svn mergeinfo subcommand
cmpilato committed a new svn mergeinfo subcommand that reports the
merged and available revisions. Here are some output samples:
$ svn mergeinfo .
Path:
Merge source: file:///Users/username/repositories/conflicts/trunk
Merged ranges: r0:4, r8:9, r12:16, r21:22
Eligible ranges: r4:8, r9:12, r16:21, r22:25
$ svn mergeinfo .
Path:
Merge source: file:///Users/username/repositories/merge-tracking/branches/a
Merged ranges: r3:11
Eligible ranges: r11:17
Merge source: file:///Users/username/repositories/merge-tracking/branches/b
Merged ranges: r10:17
Eligible ranges:
So there are a few questions up for debate.
1) Currently it shows both merged and eligible ranges. Now that I
see it, I like this idea. I imagine we could add --avail and --merged
as options if we didn't want it to be this way. I like the way it is.
2) He writes out full URL's. The svn:mergeinfo property uses
relative URL's (for good reason). I understand why he is using full
URL's. I think the output would be more readable if it was relative
to the root. I would not change the API, just the CLI output. I do
not feel strongly about this.
3) He shows revision ranges in the format we currently support for
svn merge. I say currently because issue 2818 might impact this.
Merge itself, now outputs the actual revisions it is merging. The
mergeinfo property describes the actual revisions that are merged. I
kind of prefer this myself to the other format. I know on IRC some
people have questioned this (at least in terms of the merge output).
They think it should be consistent with the input to merge. I
understand that argument but think the current output makes more sense
to the user and situation.
So what should this command do?
(I am going to use the term "old format" to mean the way svn merge
currently accepts a revision range. And "new format" to refer to the
way svn:mergeinfo records it.)
Something that would be both consistent and inconsistent at the same
time would be to use the "new format" for reporting merged revisions,
and the "old format" for the eligible ranges. This would allow the
eligible revision range to be passed directly to svn merge if desired.
This might sound stupid, maybe it is, but I think it does make some
sense from a user perspective and overall consistency.
Here is what the above output would look like:
$ svn mergeinfo .
Path:
Merge source: /trunk
Merged revisions: 1-4, 9, 13-16, 22
Eligible ranges: r4:8, r9:12, r16:21, r22:25
$ svn mergeinfo .
Path:
Merge source: /branches/a
Merged revisions: 4-11
Eligible ranges: r11:17
Merge source: /branches/b
Merged revisions: 11-17
Eligible ranges:
And for completeness, here is what it would look like if we simply
used the "new format" for both:
$ svn mergeinfo .
Path:
Merge source: /trunk
Merged revisions: 1-4, 9, 13-16, 22
Eligible revisions: 5-8, 10-12, 17-21, 23-25
$ svn mergeinfo .
Path:
Merge source: /branches/a
Merged revisions: 4-11
Eligible revisions: 12-17
Merge source: /branches/b
Merged revisions: 11-17
Eligible revisions:
I changed the word "ranges" to be "revisions" when reporting using the
"new format" and also dropped the r and : in favor of a -
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New svn mergeinfo subcommand
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On 9/20/07, Peter Samuelson <pe...@p12n.org> wrote:
>> [Mark Phippard]
>>> I think you are wrong on this. The ranges in svn:mergeinfo are the
>>> actual revisions that have been merged, not the range you would have
>>> used on svn merge.
>> My mistake. I assumed it was the other, based on your original example:
>>
>> $ svn mergeinfo .
>> Path:
>> Merge source: file:///Users/username/repositories/conflicts/trunk
>> Merged ranges: r0:4, r8:9, r12:16, r21:22
>> Eligible ranges: r4:8, r9:12, r16:21, r22:25
>>
>> The ranges in question seem to support my hypothesis: that the numbers
>> are _not_ inclusive on both sides, but only on one side. Or am I
>> interpreting that data wrong?
>
> That is because Mike chose to take the data from the mergeinfo
> property and "normalize" it into this format. Here is the property:
>
> $ svn pg svn:mergeinfo
> /trunk:1-4,9,13-16,22
Actually, I didn't make an explicit decision to that "normalization" -- the
mergeinfo parsing/unparsing utility functions do this for me. As you can
see with simple code inspection, I print what is given me in the
merge_range_t structure:
printf("r%ld:%ld%s", range->start, range->end,
(i == (ranges->nelts - 1)) ? "\n" : ", ");
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: New svn mergeinfo subcommand
Posted by Mark Phippard <ma...@gmail.com>.
On 9/20/07, Peter Samuelson <pe...@p12n.org> wrote:
>
> [Mark Phippard]
> > I think you are wrong on this. The ranges in svn:mergeinfo are the
> > actual revisions that have been merged, not the range you would have
> > used on svn merge.
>
> My mistake. I assumed it was the other, based on your original example:
>
> $ svn mergeinfo .
> Path:
> Merge source: file:///Users/username/repositories/conflicts/trunk
> Merged ranges: r0:4, r8:9, r12:16, r21:22
> Eligible ranges: r4:8, r9:12, r16:21, r22:25
>
> The ranges in question seem to support my hypothesis: that the numbers
> are _not_ inclusive on both sides, but only on one side. Or am I
> interpreting that data wrong?
That is because Mike chose to take the data from the mergeinfo
property and "normalize" it into this format. Here is the property:
$ svn pg svn:mergeinfo
/trunk:1-4,9,13-16,22
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New svn mergeinfo subcommand
Posted by Peter Samuelson <pe...@p12n.org>.
[Mark Phippard]
> I think you are wrong on this. The ranges in svn:mergeinfo are the
> actual revisions that have been merged, not the range you would have
> used on svn merge.
My mistake. I assumed it was the other, based on your original example:
$ svn mergeinfo .
Path:
Merge source: file:///Users/username/repositories/conflicts/trunk
Merged ranges: r0:4, r8:9, r12:16, r21:22
Eligible ranges: r4:8, r9:12, r16:21, r22:25
The ranges in question seem to support my hypothesis: that the numbers
are _not_ inclusive on both sides, but only on one side. Or am I
interpreting that data wrong?
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New svn mergeinfo subcommand
Posted by Mark Phippard <ma...@gmail.com>.
On 9/19/07, Peter Samuelson <pe...@p12n.org> wrote:
>
> [Mark Phippard]
> > It'd be cool if you could do this and get the exact results back efficiently:
> >
> > svn log -r 1:4, 9, 13:16, 22
> >
> > Then you could truly paste the results.
>
> Hmm, not quite. This is the old misfeature where -rM:N means something
> different in 'svn log' than in most other commands. (In particular it
> includes the left side of the range.) The meaning of ranges in
> 'mergeinfo', of course, is the same as in 'diff' and 'merge'.
>
> It's the same reason you can't expect 'svn log -r4:8' to refer to the
> same changes as 'svn diff -r4:8' today.
I think you are wrong on this. The ranges in svn:mergeinfo are the
actual revisions that have been merged, not the range you would have
used on svn merge. What I was proposing above is that the command
output the same -- which would also be the values you would feed svn
log.
Personally, I was not basing my opinions on what our tool accepts but
on what a user is likely thinking about. If I ask what revisions have
been merged or even are eligible to be merged, I would expect to see
those revisions, not the N-1 syntax that is needed to get them.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New svn mergeinfo subcommand
Posted by Peter Samuelson <pe...@p12n.org>.
[Mark Phippard]
> It'd be cool if you could do this and get the exact results back efficiently:
>
> svn log -r 1:4, 9, 13:16, 22
>
> Then you could truly paste the results.
Hmm, not quite. This is the old misfeature where -rM:N means something
different in 'svn log' than in most other commands. (In particular it
includes the left side of the range.) The meaning of ranges in
'mergeinfo', of course, is the same as in 'diff' and 'merge'.
It's the same reason you can't expect 'svn log -r4:8' to refer to the
same changes as 'svn diff -r4:8' today.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New svn mergeinfo subcommand
Posted by Mark Phippard <ma...@gmail.com>.
On 9/19/07, C. Michael Pilato <cm...@collab.net> wrote:
> > 2) He writes out full URL's. The svn:mergeinfo property uses
> > relative URL's (for good reason). I understand why he is using full
> > URL's. I think the output would be more readable if it was relative
> > to the root. I would not change the API, just the CLI output. I do
> > not feel strongly about this.
>
> Eh. Whatever. Maybe this will be an excuse to expose an
> svn_client_repos_root_url() function, then. :-)
Like I said, I do not feel strongly. I just find the truncated format
easier to digest.
> > Something that would be both consistent and inconsistent at the same
> > time would be to use the "new format" for reporting merged revisions,
> > and the "old format" for the eligible ranges. This would allow the
> > eligible revision range to be passed directly to svn merge if desired.
> > This might sound stupid, maybe it is, but I think it does make some
> > sense from a user perspective and overall consistency.
> >
> > Here is what the above output would look like:
> >
> > $ svn mergeinfo .
> > Path:
> > Merge source: /trunk
> > Merged revisions: 1-4, 9, 13-16, 22
> > Eligible ranges: r4:8, r9:12, r16:21, r22:25
>
> [...]
>
> > And for completeness, here is what it would look like if we simply
> > used the "new format" for both:
> >
> > $ svn mergeinfo .
> > Path:
> > Merge source: /trunk
> > Merged revisions: 1-4, 9, 13-16, 22
> > Eligible revisions: 5-8, 10-12, 17-21, 23-25
>
> I've no problem with this latter format over what's in there now, but the
> inconsistent output of the first proposal is no good. You've made the
> assumption that folks will copy-n-paste the eligible ranges but not the
> merged ones, and frankly that assumption is bogus. I'm just as likely to
> run 'svn log' on a range of merged revisions as I am to run 'svn merge' on a
> range of not-yet-merged revisions, so using two different formats doesn't
> strike me as anything but confusing.
If the goal is cut and paste, it seems like my first proposal is the
best one, with the exception that we should use ":" instead of "-" as
the values in that proposal are what you would need to paste into log
(in the case of merged revisions) and merge (in the case of eligible
revisions.
It'd be cool if you could do this and get the exact results back efficiently:
svn log -r 1:4, 9, 13:16, 22
Then you could truly paste the results.
I assume that regardless of the changes to the output, the actual
underlying API is sort of set now and could be exposed via JavaHL?
Finally, should we consider an option that suppresses the revisions
that occurred prior to the creation of the target? In the example
above, the branch was created in r5, which primed it with trunk 1-4.
Should those show as merged revisions in this command?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New svn mergeinfo subcommand
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> cmpilato committed a new svn mergeinfo subcommand that reports the
> merged and available revisions. Here are some output samples:
>
> $ svn mergeinfo .
> Path:
> Merge source: file:///Users/username/repositories/conflicts/trunk
> Merged ranges: r0:4, r8:9, r12:16, r21:22
> Eligible ranges: r4:8, r9:12, r16:21, r22:25
>
> $ svn mergeinfo .
> Path:
> Merge source: file:///Users/username/repositories/merge-tracking/branches/a
> Merged ranges: r3:11
> Eligible ranges: r11:17
> Merge source: file:///Users/username/repositories/merge-tracking/branches/b
> Merged ranges: r10:17
> Eligible ranges:
>
>
> So there are a few questions up for debate.
>
> 1) Currently it shows both merged and eligible ranges. Now that I
> see it, I like this idea. I imagine we could add --avail and --merged
> as options if we didn't want it to be this way. I like the way it is.
Yeah, I was originally thinking about making two different commands, but
having one worked too nicely.
> 2) He writes out full URL's. The svn:mergeinfo property uses
> relative URL's (for good reason). I understand why he is using full
> URL's. I think the output would be more readable if it was relative
> to the root. I would not change the API, just the CLI output. I do
> not feel strongly about this.
Eh. Whatever. Maybe this will be an excuse to expose an
svn_client_repos_root_url() function, then. :-)
> Something that would be both consistent and inconsistent at the same
> time would be to use the "new format" for reporting merged revisions,
> and the "old format" for the eligible ranges. This would allow the
> eligible revision range to be passed directly to svn merge if desired.
> This might sound stupid, maybe it is, but I think it does make some
> sense from a user perspective and overall consistency.
>
> Here is what the above output would look like:
>
> $ svn mergeinfo .
> Path:
> Merge source: /trunk
> Merged revisions: 1-4, 9, 13-16, 22
> Eligible ranges: r4:8, r9:12, r16:21, r22:25
[...]
> And for completeness, here is what it would look like if we simply
> used the "new format" for both:
>
> $ svn mergeinfo .
> Path:
> Merge source: /trunk
> Merged revisions: 1-4, 9, 13-16, 22
> Eligible revisions: 5-8, 10-12, 17-21, 23-25
I've no problem with this latter format over what's in there now, but the
inconsistent output of the first proposal is no good. You've made the
assumption that folks will copy-n-paste the eligible ranges but not the
merged ones, and frankly that assumption is bogus. I'm just as likely to
run 'svn log' on a range of merged revisions as I am to run 'svn merge' on a
range of not-yet-merged revisions, so using two different formats doesn't
strike me as anything but confusing.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand