subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandt, Servatius (External)" <servatius.brandt.exter...@ts.fujitsu.com>
Subject Extending --reintegrate checks to 2-URL merge
Date Tue, 22 Jun 2010 15:06:29 GMT
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@100 ^/feature@HEAD

However, the command above seems to execute simply

	svn merge ^/trunk@HEAD ^/feature@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@ts.fujitsu.com


Mime
View raw message