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.)
- application/pgp-signature attachment: stored
Received on Sun Sep 17 21:55:40 2006