This is an suggestion to improve the --reintegrate option to perform
similar checks on a 2-URL merge as it already does when used with
a 1-URL merge.
This would be helpful in the following scenario:
Beside the trunk there are two branches
"feature" from trunk:50,
"release" from trunk:80,
all at the top of the repository.
All trunk changes up to r100 have been merged into "feature" and
committed as r101. There are some more commits, r102 on "feature" and
r103 and r104 on "trunk". The latter (r104) has also been merged to
"release" and committed as r105.
I would like to use the commands
cd WC-release
svn merge --reintegrate ^/trunk ^/feature
to integrate the new feature into the release branch (agile release
strategy). I would expect the merge --reintegrate command to do the
following:
1. Check that the working copy WC-release of "release" is clean
(single revision, no switched children, no sparse checkout).
2. Check that there is a single range of revisions merged from
"trunk" to "feature", without any unmerged revisions in
between (in this case r51:100).
3. Check that no subtree merge from "trunk" to "feature" has
been done (to protect against a partial merge of r103, for
instance).
4. Determine the last revision that was merged from "trunk" to
"feature" (in this case r100).
5. Perform a 2-URL merge, using the revision determined in 4 for
"trunk", so here: invoke
svn merge ^tr...@100 ^/feat...@head
However, the command above seems to execute simply
svn merge ^/tr...@head ^/feat...@head
(Actually, I did not check 2 and 3, but 1, 4, 5 are missing from my
experiments.)
The problem is that this removes the change made in r105 from "release"
because this change was initially committed as r104 on "trunk" but not
merged to "feature". If step 5 were done, the change r105 would have
survived on "release".
It would be helpful if
cd WC-release
svn merge --reintegrate ^/trunk ^/feature
would perform similar steps as
cd WC-trunk
svn merge --reintegrate ^/feature
And
cd WC-trunk
svn merge --reintegrate ^/trunk ^/feature
should then do exactly the same as the 1-URL command just mentioned.
Extending the --reintegrate checks on the 2-URL merge would save users
from doing all the safety checks manually. If this is not possible for
some reason, --reintegrate should better report an error "not supported"
when used with a 2-URL merge.
Thanks for your time,
Servatius