On Fri, 2011-09-30, Paul Burba wrote:
> So as to keep my thoughts on the medium of record, I'm pasting my
> comments on your doc here, rather than as comments in google docs :
Thanks for all your comments, Paul.
> (Which raises a question, why aren't we keeping these notes in our own
> repository?)
I wanted to write these notes in a Subversion Wiki, as I think that's
the best medium for this kind of "sketching", so I requested one and now
we've got it I'll transfer them. The Wiki is better than a Google doc
because it's owned by the Subversion community. I'm happy to check
these notes in to the repo as well, and there are advantages (e.g.
off-line editing), I just found Google the easiest place to do the
initial flurry of editing.
> > On a dev
>
> You need to define a 'dev' branch in your terminology section.
> Assuming you mean "feature" branch.
Yup. Fixed.
> > branch, attempting to merge to parent without
> > “--reintegrate” is wrong, (except perhaps for a cherry-pick, and that
> > would be unusual). Catch this case. Possibly with hook script? Need
> > awareness of what kind of branch ‘this’ is.
>
> Awareness of "branch-roots" might be as, or more, useful or at least a
> first step to identifying branch type.
Right.
> > Catch other cases from the ‘Branching and Merging Policy’ section below.
> > On any branch, a reverse-merge of a merge in this branch’s own
> > history will not do what we expect, I think. The correct (better?) way
> > to roll back a merge is to reverse-merge the original changes from the
> > source branch.
>
> A couple advantages to simply reverse merging from the branch's own history:
>
> 1) Avoidance of any conflicts the original merge caused.
Oh yes, I overlooked that important point.
> 2) If the merge we want to reverse was a reintegrate merge from a
> backport branch, the exact merge to perform is non-obvious. [...]
Yes, or indeed if it was any non-trivial merge. Two very good reasons
why we'd really like to be able to reverse-merge from our own history.
In writing this point I was concentrating on (what I perceived to be)
the difference in what's tracked between those two ways of doing it.
Since writing that I've realized that the subject of reverse-merging is
complex enough that it needs a whole section devoted to it, so I won't
dwell on this right now, I'll just note your good observations.
[...]
> > Common misconceptions
> >
> > That merging from A to B will make B look like A.
> > A client said “I merged A to B, then modified B, and now need
> > to revert the change on B; maybe I could do that by merging A to B
> > again”.
>
> Is 'A' a revision, a branch or both? “I merged A to B" makes it sound
> like a revision (or revisions), but then it clearly is referring to a
> branch.
Branches; clarified.
> > In that case, I think the merge from A to B was a
> > “reintegrate” which does indeed pretty much make B look like A.
> > (Source: WD support ticket #3013.)
>
> Probably pointless nitpick, but is this really a "common" misconception?
"Too common" then: I've heard it more times than I'd like to.
[...]
> > $ svn merge --reintegrate ^/branches/feature2
> >
> > Reintegrating ‘^/branches/feature2’ into working copy of ‘^/branches/dev1’
> > and then a summary of the current merging status:
>
> If a user is unaware of what working copy they are operating on, then
> this notification is unlikely to help them.
I was helping a user recently who was switching between different WCs
and the disk path was the only easily visible indication and was not
always a good indication of which repo branch it was attached to. The
user was finding it hard to keep track of which was which, particularly
as the concept of merges always being done in a WC of the *target*
branch was not an ingrained concept.
> I don't see much harm in
> it alone, but as we pile on more notifications (below) I think we run
> the risk of overloading the merge output (more than it is already!) to
> the point where users reflexively ignore it.
Good point to be careful about info overload.
> > Previous merges from ‘^/branches/feature2’ into ‘^/branches/dev1’:
> > 4 source changes (latest: r144) in 2 merges (latest: r145)
>
> I think we are crossing into "too much information" territory if 'svn
> merge' starts telling what merges have *previously* been committed.
> Isn't that the domain of 'svn mergeinfo'? See my above concern about
> notification overload.
Yes, fine, I'm just trying to find what kinds of info are useful and I
was indeed thinking about the 'svn mergeinfo' command when sketching
this out.
> If I'm in the minority on this view, I'd suggest that these
> notifications either appear after the merge is complete or be repeated
> again at the end; so as to be more noticeable.
Good thoughts.
> > and any warnings:
> > warning: working copy contains modifications (all in ‘docs/’)
> > warning: working copy is not up to date
> > warning: ‘^/branches/feature2’ is not up to date with ‘^/branches/dev1’:
>
> Doh, can't believe we've never thought of this before, but recall how
> 'svn switch' now disallows switching to an unrelated branch:
[...]
> We probably want something analogous for 'svn merge', which happily
> allows me to do something nonsensical like this: [...]
Yes, good.
> > Reporting -- What “svn mergeinfo” Should Say
[...]
> > Merged from ^/trunk:
> > Origin-1214, 1216-1234
>
> Keep in mind that for long-lived release branches this information is
> never going to be very tidy -- the desire for tidy (i.e. human
> readable) output for svn mergeinfo being a common theme elsewhere in
> this thread. Consider our 1.6.x branch, [...]
Yes. I've nothing against printing all the verbose info in cases where
that's what the user wants. In a cherry-picking scenario that can be a
lot of revs.
In a non-cherry-picking scenario, however (e.g. a feature branch on
which catch-up merges have been done), the revs recorded as having been
"merged" can be displayed as a single range (or perhaps a few ranges
with gaps between them, as illustrated in the example above), whereas
the list of *operative* changes that have been merged is a long list.
Therefore it's sometimes useful to display the range of "considered as
merged" revs, and sometimes more useful to display the "operative
changes that were merged", depending on what the user's looking for.
Part of our UI design job here is to decide when to display all
considered ranges and when to display only operative revs. I feel this
is going to become clear.
Another point is that we can have a verbose mode that lists all the revs
(or ranges) versus a quiet mode that prints a summary such as "777
changes found, oldest is r875965, youngest is r1151036" or whatever.
> > Automatic identification of the parent branch:
> > $ svn mergeinfo
> > Parent branch is ^/trunk.
> > [... continue as for “svn mergeinfo ^/trunk” …]
> > Failed to identify a parent branch:
> > $ svn mergeinfo
> > svn: No parent branch configured for ^/branches/B
> > When no relationship is configured between this and the specified branch:
> > $ svn mergeinfo ^/branches/B2
> > No declared relationship between ^/branches/B and ^/branches/B2.
> > Merged from ^/branches/B2:
> > 905,970-977
> >
> >
> > Mergeinfo should be “recursive” by default, reporting any sub-tree
> > differences, where presently it does not.
>
> One possible point in favor of keeping 'svn mergeinfo' non-recursive
. o O (No, no, don't say it...)
> by default: That recursion takes time, possibly a lot of time if you
> have 1000's of subtrees with explicit mergeinfo. But that's pretty
> minor since 'svn merge' operates at depth=infinity by default, so 'svn
> mergeinfo' probably should too...so I think that means I agree!
. o O (Phew, disaster averted :-)
[...]
> > Mergeinfo Diff (bug)
[...]
>
> Might be worth putting a link to the already lengthy discussion on
> this topic: http://svn.haxx.se/dev/archive-2011-09/0201.shtml
Linked.
> > Terminology - A Typical Branching and Merging Policy
[...]
> The term 'sync' merge is (more?) frequently used to describe this type
> of merge too.
Noted.
[...]
> we should define 'cherry-pick'.
Defined.
> > A merge from a Release Branch to its parent could be a catch-up or
> > a cherry-pick. (### Does a catch-up work properly if you’ve done
> > cherry-picks in the other direction? Might not.)
>
> I'm not sure I see the use case where we'd want to do a sync/catch-up
> merge from a release branch (as you've defined it) back to the parent.
Imagine we make some bug fixes on trunk and back-port them to 1.7.x, and
make other bug fixes initially on 1.7.x and forward-port them to trunk.
The purpose of this (let's say daily) "catch-up" merge from release
branch to its parent branch is to accomplish the forward-porting of all
bug fixes that have been made on 1.7.x since yesterday.
> Does it work properly?
No, Subversion doesn't (yet) support this.
[...]
> > A merge to or from a Release Branch may be forbidden in one direction,
> > according to local policy.
>
> Are you getting at the fact that we may want to discourage merges from
> release branches back to the parent? Or something else?
I'm getting at the fact that some projects (like ours in fact) have a
policy that fixes on a release branch should never be made and committed
directly there but should instead be made on trunk and merged to the
release branch, and other projects may have a policy the other way
around. If we were to support a policy configuration of some sort then
these are options that we may want to support in order for the
Subversion client to either force or coax users into doing what their
project admins have said they should do.
- Julian
Received on 2011-10-04 19:22:03 CEST