Thanks for the comments, Mark. Responses in line...
Mark Phippard wrote:
> Julian Foad wrote:
>>
>> SHOWING SUMMARIZED MERGEINFO
>>
>> [[[
>> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
>> [...]
>> Revision range(s) recorded as merged:
>> to target path '.':
>> 875965,875968,...,1151036 (477 ranges) from same relative path
>> to target path 'CHANGES':
>> 875962-1130989 from same relative path
[...]
>> I want "svn mergeinfo" to show a high-level summary of the situation.
>> This currently shows the parts of the mergeinfo on the target that
>> pertain to the source branch, including subtrees, in a summarized
>> form. It could be summarized better; for instance, group together
>> several target paths that all have the same source ranges merged to
>> them.
>>
>> After that it currently goes on to print the "merged" and then the
>> "eligible" revisions as lists of individual "operative" (non-empty)
>> changes, with a (currently fake) classification of each change as a
>> "merge" or an "original commit". That's more because I'm interested in
>> the ability to do such classification, and not that I would
>> necessarily want to show that in the "mergeinfo" command output.
>
> You might have posted it already but is there a "big-picture" outline
> somewhere of where you are going with this?
My goal in one sentence is to stop people accidentally messing up by
not understanding what they're doing. The closest descriptive
document is <http://wiki.apache.org/subversion/SimpleAndSafeMerges>.
I believe one of the main reasons people get their mergeinfo into a
mess (from our point of view as developers) is by running Subversion
merges without having the correct understanding of what those commands
are doing, and by not having a good enough view (reporting) of what
they have done. In other words, we make it too easy for users to
execute silly merges and not notice until it's too late. We should
steer them towards the most common cases and display feedback that
indicates whether they're doing something "simple and expected" or
something "wierd" that they might not have meant.
> It looks good but you are
> saying that this is not how you intend to leave it so I am not sure what to
> comment on. Improving the formatting seems like a good idea. I assume you
> do not ultimately plan to mix the new formatting and the old formatting in
> the same output. I assume the command line options would determine which
> format you get.
Yes, I'm thinking if you specify --show-revs={eligible|merged} you'll
get the old simple list of revs, and if you don't specify either of
those then you'll get the new summary instead. I'm intending the new
output to include info about both eligible and merged revs). But
largely this is designing 'on the fly', hence asking for any and all
comments from time to time.
>> IDENTIFYING BRANCH ROOTS
>>
>> [[[
>> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
>> Branch marker: 'subversion-source-tree' (found on both source and target)
>> [...]
>> ]]]
>>
>> This looks for a branch root marker property on the specified
>> directory. The property name would be 'svn:branch-root' and the value
>> would be a string that (more or less uniquely) identifies the
>> 'project' (for want of a better word) of which this is a branch.
>> Currently, just for testing, the property it looks for is the first
>> ten characters of 'svn:ignore', which tends to work moderately well
>> for ad-hoc testing against our own source tree because it exists and
>> starts with 'ChangeLog*' in the root of every branch and (I guess)
>> nowhere else.
>
> This feature concerns me the most. I assume we are not proposing to add
> this marker just for this one subcommand?
Quite right.
> I would like to see the big
> picture of what we would do this marker so we can discuss its format and its
> ramifications.
> I have a use-case for me where subtree merges are essential (and normal) so
> I do not want to see any movement away from supporting them.
I do not intend to take away any functionality from those who know
exactly what they want to do. (This is not the 'newmerge' project.)
> Eclipse
> projects very commonly have a structure like this:
> /trunk
> |- plugin1
> |- plugin2
> |- plugin3
> These plugins are all related to each other so I always branch at /trunk.
> However, in Eclipse, you do not checkout or work with trunk. You checkout
> the individual projects and these typically manifest on your disk as 3
> distinct working copies. If you are using Eclipse to merge, then you are
> doing subtree merges to each of these projects.
> Sometimes I will use the command line or TortoiseSVN and have the entire
> tree checked out and do merges at the parent.
> Subversion handles this all quite well and I do not want to see it lost.
OK, it's very useful to have this as en example of a good use for
subtree merging.
> Anyway, that is all just as an aside. I am not against adding the feature,
> just want to see what we plan to do with it. If you could only do a merge
> to branch-root I would have problems with that.
>> IDENTIFYING THE SOURCE BRANCH AUTOMATICALLY
>>
>> [[[
>> $ svn mergeinfo
>> Assuming source branch is copied-from source of target branch. ###
>> target is implicit '.'
>> [...]
>> Source branch: ^/subversion/trunk (r1189704)
>> Target branch: ^/subversion/branches/showing-merge-info (working copy)
>> [...]
>> ]]]
>>
>> At the moment this only looks for the copied-from branch, which is not
>> good enough; if we do this at all then we need a way to . Stefan also
>> suggested it should only select a source automatically when it finds a
>> branch root marker, as that means someone has deliberately enabled the
>> feature.
>
> I do not see how we can do anything other than selected the copied-from
> unless we are going to add a feature that allows the user to specifically
> set it somewhere, like this branch-root property. That seems like a problem
> though because our normal SVN behaviors would want to propagate those
> property changes to other copies and in merges.
For now, yes; later I would like to explore the idea of the user
providing some info somewhere about how branches are related, but I
haven't gone anywhere with that idea yet.
> MAKING MERGE EXPLAIN WHAT IT'S DOING
>>
>> [[[
>> $ svn merge ^/subversion/trunk
>> Sync merge from '^/subversion/trunk' into '.' (a working copy of
>> '^/subversion/branches/showing-merge-info')
>> [... and maybe a summary of the revision ranges it's looking to pull in
>> ...]
>>
>> $ svn merge --reintegrate ^/subversion/branches/showing-merge-info
>> Reintegrate merge from '^/subversion/branches/showing-merge-info' into
>> '.' (a working copy of '^/subversion/branches/trunk')
>> The reintegrate merge will be equivalent to:
>> merge ^/subversion/trunk_at_1188748
>> ^/subversion/branches/showing-merge-info_at_1189710 .
>> [...]
>> ]]]
>>
>> I've only just started with this and haven't checked all of this in.
>
> Have to say that I do not really see the value in this one. Seems you could
> just as easily argue that any of our subcommands is hard and confusing and
> propose adding this sort of output to any of those commands.
> $ svn status .
> Checking the status of "." (a working copy of ^/trunk)
> Seriously?
No way. For a start, most commands are read-only; if you run a bunch
of status commands on targets that don't exist or aren't in the
working copy you thought they were or whatever, the only negative
consequence is your momentary confusion over what you see; no state
change occurs. On the other hand, doing a record-only merge with the
wrong source and target (particularly if they are different paths
relative to the branch root, like assuming src='branch1/dir/file.c'
target='branch2/' will do the Right Thing) is a too-common and fairly
devastating mistake.
I know that printing information is not the same thing as preventing
mistakes, but like I said at the start I'm looking for ways to make a
"simple" merge print a simple confirming message and a "complex" one
print something that indicates how complex it is. See for example in
my "mergeinfo" example, I have detected whether the (recorded) merge
was from/to the same relative path in the source as in the target, and
either print "from same relative path" or "from source path
'foo/bar'". I want to make that even clearer - e.g. print nothing in
the former case.
- Julian
Received on 2011-10-27 18:06:08 CEST