Mark Phippard wrote:
> On 6/15/07, Folker Schamel <schamel23@spinor.com> wrote:
>> ...
>> 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:
>
> I think you are jumping to a lot of incorrect conclusions. For
> example, I do not work on merge tracking, other than that I have been
> testing out various scenarios and reporting what I find. So do not
> paint the entire dev team with whatever comments I have made.
Sorry, I didn't want to suggest that you work on merge tracking.
All in all, my posts really don't intent to criticize someone,
but just discuss this technical issue.
I think svn is a great tool, and I hold you and the other svn
developers in high esteem!
>> 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.
>
> Honestly, I do not see how you can spell out this whole scenario and
> then still make the wrong conclusion. If I am working on a feature
> branch, why would I not want to eventually merge that back to trunk?
Because in this scenario, the change is already present in trunk,
because it came from trunk. And merging back can just cause unnecessary
conflicts.
> And when I did, why would I not want the correct code modifications I
> made to come with it? Trunk would be broken if I did that. In
No, in this scenario, trunk gets broken if you merge the modifications.
> reality, hopefully the developer would catch the problems and they
> would have to work to do to fix it.
>
> You talked about deleting trunk and then copying the branch. I agree
> that would work, but I have not seen it done very often.
Of course, this is not ideal.
But better than causing many conflicts by trying to merge everything back.
In addition to my longer discussions in my other email,
one more argument:
Assume for a moment that no manual adjustments are necessary
when merging from trunk to branch. Hopefully this is the normal case.
Then skipping reflected changes (as svnmerge merge --bidirectional)
obviously is always the best choice. Trying to merge back reflected
changes (as svnmerge without --bidirectional) has no advantage but
only causes unnecessary conflicts over conflicts when merging
in both directions.
(Just execute my sample log using svnmerge without --bidirectional
and you will see by yourself.)
Btw, was there already some discussion with the creator of svnmerge
why he implemented the "--bidirectional" flag?
I think that considering svnmerge as svn merge-tracking prototype
and learning from that is a good idea.
And if the author of svnmerge says that --bidirectional is not really
necessary, than I would trust him, even if I don't understand the reason. ;-)
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jun 17 00:27:22 2007