Re: Account for reflected revisions when performing cyclic merges

On 6/15/07, Folker Schamel <schamel23@spinor.com> wrote:
> Daniel Rall wrote:
> > On Thu, 14 Jun 2007, Folker Schamel wrote:
> >
> >> Folker Schamel wrote:
> >>> Daniel Berlin wrote:
> >>>> ...
> >>>>
> >>>> The initial merge tracking implementation was not meant to handle
> >>>> repeated bidirectional merging, at least, as designed.
> >>>>
> >>>> ...
> >>>>
> >>>> The original goal was to provide much the same functionality as
> >>>> svnmerge.py on a per-file basis.
> >>>>
> >>>> ...
> >>> Just a note:
> >>> svnmerge provides repeated bidirectional merging by the --bidirectional flag.
> >> See also http://svn.haxx.se/dev/archive-2007-03/0234.shtml
> >
> > In the A -> B -> A case, neither Subversion nor svnmerge.py can readily
> > support bi-directional merging correctly, since Subversion does not track
> > multiple parents for a change (it only tracks one).
> >
> > We'd have to change Subversion's FS schema to make this possible.
>
> svnmerge supports bi-directional merge in the following way,
> see log below.
>
> Note that after merging c8 from branch -> trunk as new c9,
> the "svnmerge merge --bidirectional" does not merge c9 back
> from trunk -> branch, but only the trunk change c7 as new r10,
>
> This is what I meant by handling A -> B -> A correctly.
> This is B -> A in http://svn.haxx.se/dev/archive-2007-03/0234.shtml
> I don't think you need a FS schemata change for that,
> you just have to check for reflected revision during merge.
>
> Will svn merge-tracking support this particular scenario, too?
> Would be cool! :-)

Any system that simply ignores the revision in this scenario is
inherently flawed. It will lose any changes that were committed as
part of doing the merge. For example, you are working on a feature
branch and synching with trunk. Everytime you merge the trunk changes
to the branch, there might be little changes you need to make to
accomodate the branch. These get committed to the branch with the
merge. If you then simply ignore those revisions when merging back to
trunk you will be losing information.

Of course the other issue is that users can do stuff that is stupid
such as commit changes unrelated to the merge in the same commit as
the merge and those changes will also be lost.

-- 
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