The question: How should we record merge info when part of a merge
into a WC is skipped?
Garrett and I had a long discussion on IRC, where we boiled this down
to two classes of use cases for "skipped notifications", which are
hopefully helpful in addressing this problem:
"Expected" skip:
================
The skip notification results from a path which is "expected to be
missing". Garrett thinks that we should record merge info for the WC
target's entire tree.
"Unexpected" skip:
==================
The skip notification results from a path which is "obstructed" or
"missing, but expected to be there". I tend to think that we should
record only partial merge info for the parents of these paths.
Is there value in differentiating between these two types of skip
notifications for the recording of merge info?
For the masochistic *cough* interested, the IRC transcript is
attached.
On Tue, 19 Sep 2006, Kamesh Jayachandran wrote:
> 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.
- application/pgp-signature attachment: stored
Received on Wed Sep 20 02:13:40 2006