Re: Account for reflected revisions when performing cyclic merges

On 6/8/07, Daniel Berlin <dberlin@dberlin.org> wrote:
> On 6/7/07, Daniel Rall <dlr@collab.net> wrote:
> > For an illustration of this problem, see merge (f) in this diagram:
> > http://subclipse.tigris.org/files/documents/906/37977/repos.png
> >
> > The corresponding repository is available here:
> > http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=8590&expandFolder=8590&folderID=8590
> >
> > From notes/merge-tracking.txt:
> > * Account for reflected revisions when performing cyclic merges. For
> > example: trunk is branched, then modified, and the branch is brought
> > up to date with trunk, then the branch is modified, then the branch
> > is merged to the trunk. To avoid repeated merging of changes to
> > trunk, only the modification to the branch should be applied to
> > trunk. (dlr)
> >
> > * Need an API which can refine the requested merge range from the
> > branch based on a) what changes the merge from the branch already
> > represents on trunk and b) what branch revisions were merges from
> > trunk to the branch (which should be avoided, to skip replaying
> > changes back to trunk which were made on trunk).
> >
> > I've got a patch (attached) will implements (a), filtering of
> > reflected revisions. However, Mark Phippard has pointed out that (b),
> > while it potentially causes repeated merges to occur, may be necessary
> > to handle other local mods or conflict resolution which occurred after
> > a merge.
> >
> > So, how do we handle this? Seems like we're stuck with a potential
> > re-merging of an existing set of changes, which is a large part of
> > what merge tracking is attempting to avoid.
>
> This is one of the reasons i told you we would eventually need to know
> which changes were the results of merges and where were modifies ;)
>
> Let me answer this by stating some original design goals and
> philosophy of how to get to where you want to be
>
> The initial merge tracking implementation was not meant to handle
> repeated bidirectional merging, at least, as designed.

In a private email exchange I had earlier with Dan, I said I had this
feeling that you might have already said this before, even in your
design document. It is always good to be reminded of these things.

From an operational standpoint, I do not think this is the end of the
world. You can still do one final synchronization of your feature
branch with trunk@HEAD, taking advantage of merge tracking's
assistance. And then do a two URL merge to get the feature branch
applied back to trunk.

There are some real downsides to this though:

1) We are placing burden on the users to understand what type of
merges we support and do not support.

2) Does this completely break our "auditing" story? After I merge
the feature branch back to trunk it sounds like I will have lost that
visibility back to the revisions on the branch.

Are there still some solutions we can apply in our current model?

Suppose I am in my trunk WC and I run:

svn merge $REPOS/feature-branch

Could we determine that feature-branch is caught up to trunk at rX do
a two-URL merge under the covers? As David James suggested?
Likewise, could we error out if the branch is not in this sort of
state and force the user to give us more information?

What about the audit info? Is there a way to bring mergeinfo along in
this sort of merge so that we will still have that option?

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org