Daniel Rall wrote:
> On Fri, 15 Sep 2006, Garrett Rooney wrote:
>
>
>> On 9/15/06, Daniel Rall <dlr@collab.net> wrote:
>>
>>> As a follow-up to r21504, I fixed merge_tests.py 7 and 8 in r21511
>>> (basically by reverting earlier r20438, which made the tests incorrect
>>> now that the code is closer to being correct).
>>>
>>> Test 17 seems to be a little more tricky, as part of its merge
>>> succeeds, and part of it is skipped.
>>>
>>> Under dir "C", we create unversioned file "foo". Then we merge a tree
>>> ("F") which contains versioned file "foo" and some other stuff into
>>> "C":
>>>
>>> WC:
>>> ---
>>> C/
>>> foo
>>>
>>> Merge source:
>>> -------------
>>> F/
>>> foo
>>> Q/
>>> bar
>>>
>>> "foo" is skipped (because it's obstructed), while "Q" and "Q/bar" are
>>> merged successfully. Where in the WC should the merge info be
>>> recorded?
>>>
>>> My feeling is that merge info should apply to "Q" (and thus implicity
>>> to "bar", by inheritance). It should not apply to "foo" (because it
>>> was not merged). However, what about "C", which had partial merge of
>>> r2 succeed? Because part of the merge was skipped, I tend to think
>>> that it should not have merge info recorded on it.
>>>
>> I actually disagree, it should be recorded because part of it
>> succeeded. Similar to what happens if we get a conflict on part of a
>> file, once the conflict is resolved (perhaps excluding the portion
>> that conflicted entirely) we still record that the merge of that
>> revision occurred.
>>
>
> A conflict is a somewhat different situation than a skip, as all of a
> merge into the WC actually does occur (rather than parts of it being
> skipped). For a conflicted file, the content you intended to merge in
> is placed into target file surrounded by conflict markers, and that
> the WC maintains state flagging the file as conflicted. For a skipped
> target, the merge does not occur at all, and the WC maintains no state
> indicating that part of the merge was skipped.
>
> This difference is important when subsequently attempting to complete
> the merge of the skipped target. If merge info for a revision has
> been recorded saying that the entirety of the merge was successful
> (even if part of it was skipped), how do you later apply the remainder
> of the merge to targets which were skipped only accidentally?
>
> Taking the above scenario as an example, if I remove unversioned file
> "foo" from my WC, and attempt to re-merge the same revision of "F"
> into "C" in my WC (to add the "foo" I'd previously skipped), the
> merge-tracking branch should really avoid merging of the revision if
> it already recorded the entire revision as merged. Given that, how do
> I 1) know that I haven't already merged in "foo", since my merge info
> indicates that I have, and 2) easily merge in "foo" after removing the
> unversioned file of the same name from my WC? (Sure, you could do
> this with 'svn cat', but that's not exactly obvious to your average
> user.)
>
I would go with not recording the 'svn:mergeinfo' for the root of the
target, if any of the children(grand ... children) got skipped and
record *optimally* the 'svn:mergeinfo' for the children with successful
merges.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 19 16:06:09 2006