David Glasser wrote:
> On Jan 29, 2008 9:46 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>
>> 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?
>>
>
> Sure, that's a real use case, but I don't think that the 2897 work
> fixes that. As far as I understand it, as soon as any diff causes a
> conflict anywhere the 2897 branch gives up on trying to do anything
> special.
No it just leaves that *reflected range* and continues with others.
Let me take the following scenario(I am assuming a sparse merge sceario so
I may left out few instructions for brevity.)
1)We have /trunk/test.c with the following contents at r1.
#include <stdio.h>
int main(void)
{
printf ("I am from trunk");
return 0;
}
2)Mike makes a branch of /trunk as /b1 at r2.
In the branch he wants to change the output of the above program to "I
am from nowhere".
Meanwhile he sees someone doing a commit to '/trunk/test.c' at r3 with
the following
diff(change of remove space before parenthesis, pure stylistic change).
- printf ("I am from trunk");
+ printf("I am from trunk");
Here Mike can do 2 things described by 3a and 3b series.
3a1)He decides to merge this stylistic change from /trunk before making
his code change
which will definitely give raise to conflict if done later. And continue
with his development and make one
single commit.(Making 2 different commit is older style, making it in
one commit is issue-2897 style).
3a2)He commits both merge and his change in one commit at r4 which turns
out to be the following diff.
- printf ("I am from trunk");
+ printf("I am from nowhere");
3a3)Merge /b1 back to /trunk, This merge will be smooth and conflict free.
3b1) Make his modifications first at r4 via the following diff
- printf ("I am from trunk");
+ printf ("I am from nowhere");
3b2) merge r3 from /trunk, This will give raise to a conflict which he
resolves with a following diff
- printf ("I am from nowhere");
+ printf("I am from nowhere");
3b3) Makes a commit at r5
3b4)Merge /b1 back to /trunk.
3b41)r4 would give a conflict(It is not a reflective merge but *normal
merge*,
Assume the user resolves this conflict with '--accept=theirs',
Subsequent merge of r5(reflective) will be smooth.
If he chooses to resolve r4 merge in other way, he need to
resolve other conflicts,
where svn can not help.
If someone sees some special case to make system aware of,
please detail them, I will see how we
can do that.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
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-30 10:41:49 CET