Re: RFC: Quick question on how --reintegrate merges should behave

On Tue, Nov 18, 2008 at 10:49 AM, Paul Burba <ptburba_at_gmail.com> wrote:
> A quick question on how we'd prefer reintegrate merges to work:
> ~~~~~
>
> Use Case 1:
>
> Copy 'trunk_at_1' to 'branch' in r2
> Make a change to 'trunk' in r3
> Make a change to 'branch' in r4
> Update the 'trunk' WC to r4
>
> Then try to reintegrate 'branch' to 'trunk'. Should this:
>
> A) Fail and require that r3 be merged from 'trunk' to 'branch' before
> reintegrate will work.
>
> or
>
> B) Merge the diff between 'trunk' and 'branch's youngest common
> ancestor and 'branch_at_r4', i.e. TRUNK_URL_at_1 BRANCH_URL_at_4 to 'trunk'.
>
> The current behavior is 'B'. Note that there is the possibility of a
> conflict between r3 and r4.
>
> ~~~~~
>
> Use Case 2:
>
> Copy 'trunk_at_1' to 'branch' in r2
> Make a change to 'trunk' in r3
> Update the 'trunk' WC to r3
>
> Then try to reintegrate 'branch' to 'trunk'. Should this:
>
> A) Fail and require that r3 be merged from 'trunk' to 'branch' before
> reintegrate will work.
>
> or
>
> B) Fail with a message indicating that there is nothing to reintegrate
> or
>
> C) Actually do the merge of TRUNK_URL_at_1 BRANCH_URL_at_3 to 'trunk'. This
> is obviously a no-op diff, but mergeinfo of '/branch:2-3' would be set
> on 'trunk'.
>
> The current behavior is 'C'.
>
> ~~~~~
>
> I think the current behavior in both use cases is correct and
> consistent, but there are two merge tests that call into question what
> the correct behavior is:

I believe the current behaviors are correct and I know they were the
intended behaviors. We should not require that the branch has
received merges from trunk.

> merge_tests.py 80 'merge --reintegrate on a never-updated branch' -
> This is use case 1 and it expects behavior 'B'. Ok, no problem, that
> is what we have today.
>
> merge_tests.py 85 'merge --reintegrate should fail on stale source' -
> This is use case 2. The test expects behavior similar to 'A', that is
> the reintegrate attempt should fail (we can ignore the specifics of
> the error message for now), but what occurs is behavior 'C'.
>
> The merge_tests.py 85 test is currently marked as XFail. I think this
> XFail is wrong and should simply be removed. Does anyone disagree or
> have any concerns with the current behaviors in either of these use
> cases?

I agree with you that the current behavior is right.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org