On Fri, 2011-09-30 at 14:42 +0200, Stefan Sperling wrote:
> On Fri, Sep 30, 2011 at 12:24:04PM +0100, Julian Foad wrote:
> > I've been thinking about a bunch of issues related to merging and how to
> > help users to avoid some of the common pitfalls. One subset of my
> > thoughts is on how we can present information about merges in a more
> > user-friendly high-level way so that each time a user runs "svn merge"
> > or "svn mergeinfo" they get feedback that relates to their high-level
> > idea of what should be happening, and thus helps them to see at a glance
> > whether they issued the right command for what they wanted to achieve.
>
> I like this.
[...]
> The list of merged operative revisions can get far too long to be useful,
> especially if lots of cherry-picking is going on.
> We should collapse the default output in some way to keep it brief.
Yup, I totally agree with collapsing long output by default.
> Also, I am not sure if users tend to think in terms of "operative" and
> "non-operative" revisions. More generally, there is one big range
> from which revisions can be merged (between point-of-branch-creation
> and HEAD). Within this range, we have one or more subranges which
> have been merged or have not been merged yet. We can further divide
> revisions within each range into operative and non-operative revisions,
> but I don't think this distinction is useful in this context.
This is more interesting. Sometimes the operative revisions are
interesting, sometimes not. If I'm doing a catch-up just for the sake
of catching up, I don't really care whether any operative changes are
brought in or not, but if I'm doing a catch-up because I know that some
change I need has just been committed to my parent branch, then I want
to see that change listed (if only one of a very few operative revisions
are being merged), or at least I want to see an indication that *some*
operative change is being merged.
(I say "is being merged" because in my head I'm thinking that "svn
merge" and "svn mergeinfo" should both display similar high-level
information, or at least that what "svn mergeinfo" prints should
indicate what will be merged if I run "svn merge".)
So I think it is important to summarize both the range being considered
for merge, and the operative changes within that.
Perhaps we'll use a more user-friendly word than "operative".
> This would look as follows (example based on ^/subversion/branches/1.7.x):
>
> $ svn mergeinfo ^/subversion/trunk
> Range of revisions eligible for merging:
We already use the word "eligible" to mean non-merged so here let's
write "Range of revisions on the source branch" instead.
> r1145994-r1177620
> Merged revisions in this range:
> r1146013-r1167269 (187 gaps in this range not shown; use --verbose to see them)
> Non-merged revisions in this range:
> (601 revisions not shown; use --verbose to see them)
> Another example based on ^/subversion/branches/fs-successor-ids:
>
> $ svn mergeinfo ^/subversion/trunk
> Range of revisions eligible for merging:
> r880536-r1177620
> Merged revisions in this range:
> r1167546
> Non-merged revisions in this range:
> (8965 revisions not shown; use --verbose to see them)
>
> For branches which receive a lot of cherry-picking merges (e.g. a
> release branch) this output is concise by default and provides
> a rough idea about the state of the branch.
I think showing both merged and eligible revisions is good, rather than
the user choosing one or the other.
> It also allows users to see a list of all merged revisions via
> the --verbose switch, if they are interested in this level of detail.
>
> To answer the question 'has rX been merged into this branch?' we
> could provide a syntax such as:
> svn mergeinfo -r1146121 ^/subversion/trunk
> Currently this command seems to print the list of all merged revisions.
> I am not sure what the -r switch is supposed to do in the current
> implementation. Maybe it should print something like this instead:
>
> Changes made to '^/subversion/trunk' in r1146121 were merged to '.' in r1148486
>
> or (in case the revision was not merged):
>
> Changes made to ^/subversion/trunk in r1146121 have not been merged to '.'
>
> Of course, the '.' is the default target -- if the target was a URL I'd
> expect to see a URL instead of '.'.
>
> If multiple ranges are involved, we could print one line for each range
> to show how various revision ranges map onto one another in the context
> of merges between the branches (I made up the numbers below):
> $ svn mergeinfo -r1146121:HEAD ^/subversion/trunk
> Changes made to '^/subversion/trunk' in r1146121-r1146300 were merged to '.' in r1148486-r1148686
> Changes made to '^/subversion/trunk' in r1146304-r1146306 were merged to '.' in r1148700-r1148709
> Changes made to '^/subversion/trunk' in r1146400-r1146500 have not been merged to '.'
Yup, something like (but not quite like) that would be good.
- Julian
Received on 2011-09-30 16:31:44 CEST