On Thu, Oct 27, 2011 at 12:05 PM, Julian Foad <julian.foad_at_wandisco.com>wrote:
> 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.
>
OK.
> > 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.
>
That is about what I expected. It will be interesting to see if you can
show both eligible and merged information at the same time in a way that is
understandable. I think if the command can show some things like there the
branch came from, or the other path that the branch is merging with, could
be useful new information. Sort of like svn info for a branch. I think it
makes sense to highly condense the revisions as they are never going to add
a lot of value in this kind of context.
> >> 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.
>
So where I was going with this, and I am sure you are already thinking the
same way, is that if we are going to add this new property we probably need
to think of all (or as many) of the way we might use it so that we are
capturing all of the information we might need in the property. Of course,
we might decide we want separate properties.
> > 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.)
>
That is good to know.
> OK, it's very useful to have this as en example of a good use for
> subtree merging.
>
Thanks. I think a lot of times we tend to associate the feature with
extreme cherry picking scenarios where we might be doing our users a
disservice by trying to support them. But I do believe there are a lot of
very real world scenarios that need this feature to work.
>
> >> 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.
>
We have the "suggest merge sources" API. That might be of some help. I
recall there was a time we considered making an "interactive merge" that
used this feature to show you the merge sources and let you choose which one
you might want.
> 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.
>
>
I am not against the idea of making the output more clear and helpful. I
know you would agree that making the output more verbose does not
automatically make it easier to understand. That was all I saw in the
examples. If there are some things we can do in the output like you suggest
then that sounds interesting and might bring some value.
It will be interesting to see you keep progressing with all of this.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-10-27 20:16:11 CEST