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)?
I mean, I certainly understand that the 2897 branch supports
interesting operations. I'm just trying to figure out what use cases
would make them useful.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-29 18:33:07 CET