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

Extending --reintegrate checks to 2-URL merge

From: Brandt, Servatius (External) <servatius.brandt.external_at_ts.fujitsu.com>
Date: Tue, 22 Jun 2010 17:06:29 +0200

This is a request for an improvement of the --reintegrate option of the
merge command. I would like to use the --reintegrate option WITH, not
instead of, a 2-URL merge in the following situation:

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 result in an error "not supported"
when used with a 2-URL merge. Just ignoring the option confuses users
and may cause them to file a feature request. :-)

Thanks for your time,
Servatius

--
Servatius Brandt
Fujitsu Technology Solutions
Domagkstr. 28, D-80807 München
phone: +49 89 3222 2163
e-mail: Servatius.Brandt.external_at_ts.fujitsu.com
Received on 2010-06-22 17:23:07 CEST

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

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