Mark Phippard wrote:
> 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.
This means that you say that svn merge tracking will *intentionally*
work different than svnmerge, right?
And you imply that this decision is not because of implementation
difficulties, but because you say that the behaviour of svnmerge
is "flawed"?
In my opinion, svnmerge behaves correctly,
and trying to merge back would be flawed:
First, if a merge hadn't accommodations - hopefully the normal case -
then obviously it would be wrong to try to merge it back,
potentially causing unnecessary conflicts.
But even if there are adjustments you need to make to accommodate
to the branch, then (assuming correct usage) per definition
these adjustments are no new feature, but just branch specific adjustments.
So it would be wrong to try to merge them back.
For example, suppose trunk has a function "int oldname(int);".
In branch this function was renamed (refactoring) into "int bettername(int);",
but still providing the same functionality.
Now, when merging code containing "i = oldname(2);" from trunk to branch,
then you have to (manually) modify the code to "i = bettername(2);".
However, obviously it would be wrong to merge this change back to trunk,
because "i = bettername(2);" would be wrong in trunk.
Overall, even when accommodate during a merge, the logical content
of this changeset remains the same (assuming correct usage),
and should never applied twice by merging back.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 15 15:07:01 2007