[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Shouldn't --reintegrate used with a 2-URL merge perform checks?

From: Brandt, Servatius (External) <servatius.brandt.external_at_ts.fujitsu.com>
Date: Tue, 29 Jun 2010 16:26:49 +0200

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 ^trunk_at_100 ^/feature_at_HEAD

However, the command above seems to execute simply

        svn merge ^/trunk_at_HEAD ^/feature_at_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
Received on 2010-06-29 16:28:31 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.