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
