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 current output of 'svn mergeinfo' (one revision per line)
is suited well for consumption by scripts but not by humans.
> So I'm mocking up stuff like this (some data faked):
>
> $ cd 1.6.x
>
> $ svn mergeinfo $BRANCHES_URL/1.6.x-r878590
> Source branch: ^/subversion/branches/1.6.x-r878590 (r1177182)
> Target branch: ^/subversion/branches/1.6.x (wc)
> Source and target are marked as branches of the same project.
> Merged revision ranges:
> START-1104299,1104304,1104333-END
> Merged operative revisions:
> 1104267,1104304,1104336,1104339,1104346
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.
For instance:
Merged revision range:
1104100-1104333 (240 gaps in this range not shown, use --verbose to see them)
Or refuse to show large lists of revisions by default, like this:
Merged revision ranges:
START-1104299,1104304,1104333-END
Merged operative revisions:
(240 revisions not shown, use --verbose to see them)
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 would look as follows (example based on ^/subversion/branches/1.7.x):
$ svn mergeinfo ^/subversion/trunk
Range of revisions eligible for merging:
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.
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 '.'
Some thoughts regarding backwards compatibility:
In principle, we should keep the current output by default (for backwards
compat), and add a new switch that enables human-readable output.
However, I think that in this case breaking compatibility in favour
of user-friendliness is highly justified.
So I think the default output should be replaced completely with something
better, in addition to an --xml switch that produces XML output for
consumption by scripts. We could have the --show-revs switch enable the
old-style output (one revision per line) to provide those who have already
written scripts which parse this output with a migration path.
Received on 2011-09-30 14:43:15 CEST