David Glasser wrote:
> On Jan 29, 2008 7:42 AM, Kamesh Jayachandran <kamesh_at_collab.net> wrote:
>> I found the following differences(will add them as and when I find them).
>>
>> 1)If feature branch is not fully up-to-date with trunk(having sparse
>> merges), we will get faulty behavior.
>> a)have /trunk/test.c (r1)
>> tline1
>> tline2
>> tline3
>> tline4
>> tline5
>> b)branch /b1 from /trunk(r2)
>> c)In trunk change 'tline1'->'Tline1' and commit(r3)
>> d)In trunk change 'tline2'->'Tline2' and commit(r4)
>> e)merge r4 from trunk to /b1 and commit(r5)
>> f)merge /b1 to /trunk <-This gives a spurious conflict
>>
>> Issue-2897 branch does merge at f) correctly(Though it is broken due to
>> missing sqlite data, which I am *still* making a progress to implement
>> the FS based solution).
>
> Kamesh, that's a set of merge operations which does one (arguably more
> correct) thing with your branch and another thing without it. But
> that's not really a "use case"... what is the motiviation here? Why
> did the user only merge r4 but not r3, and then later try to
> bulk-merge back? Is the user trying to merge "all but a few specific"
> revisions, in which case a record-only merge of r3 could have happened
> (which would then allow reintegrate to work)?
David, does this scenario really surprise you all that much? I run into
this kind of thing all the time. The story goes like this:
I make a branch from trunk to rework the libsvn_fs_base implementation of
some functionality. But while my code lives out in space, my email reader
does not, and so I happen to notice that someone else has done some trivial
code formatting change that I know will cause a conflict with my branch
work. I'd like to resolve that now while my code is freshly in mind rather
than deal with it later at merge-back time. So I have a choice to make --
do I merge to my branch all the changes in the trunk since my branchpoint (a
large merge, a large commit, etc.) or do I just cherry-pick the revision
that I know will cause the problem?
Claims that one way is "better than" the other will ultimately wind up
standing on Subversion's implementation and merging prowess. A perfect
system would be able to handle either of the routes I take without odd
gyrations like manually claiming the branch-rev-of-my-cherry-picked-merge
was already merged to trunk or somesuch.
So, I don't think we have to look far for a use-case. Our task is simply to
prioritize use-cases, letting slide what we feel we need to let slide, but
ideally having comprehensible workarounds in hand.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-01-29 18:47:12 CET