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

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:

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?

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-18 16:50:11 CET