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

Merging the reintegrate-improvements branch back to trunk

From: Paul Burba <ptburba_at_gmail.com>
Date: Wed, 5 Nov 2008 10:02:50 -0500

The http://svn.collab.net/repos/svn/branches/reintegrate-improvements
branch is ready to be merged back to trunk.

This branch makes two significant changes:

1) Allow reintegrate to work when the reintegrate merge source has
explicit subtree mergeinfo, as long as that mergeinfo represents that
all of the target was previously merged to the root of the source.

Today reintegrate is largely useless because once you have subtree
mergeinfo on 'trunk', when you copy 'trunk' to 'some_branch' there is
explicit subtree mergeinfo on the latter, which stops subsequent
reintegration. But if all you have done is to make changes to
'some_branch' and synched all available revisions from 'trunk' to
'some_branch', then reintegrate's underlying 2-URL merge should be
allowed to work (i.e. the branch, edit branch, synch, reintegrate
workflow described in the Subversion book should work).

2) Improve the error message if a reintegrate merge is legitimately
thwarted by subtree mergeinfo on the source. By "legitimately" I mean
if you have done subtree merges from 'trunk' to 'some_branch' in such
a way that 'some_branch' has not had all of 'trunk' uniformly merged
to it. Previously if the reintegrate source had *any* explicit
mergeinfo we returned an error like this:

C:\SVN\src-trunk-mirror-wc>svn merge --reintegrate --accept postpone
svn: Cannot reintegrate from
Some revisions have been merged under it that have not been merged
into the reintegration target; merge them first, then retry.

I changed text of this error on the reintegrate-improvements branch,
but also added a dump of the offending subtree paths and their
mergeinfo so now a user has some hope(?) of seeing what is wrong:

C:\SVN\src-trunk-mirror-wc>svn merge --reintegrate
svn: Reintegrate can only be used if the revisions previously merged
from the reintegrate target to
are the same', but there are differences:

My hope is that a user could see the above and realize, "oh, I merged
r33301-33960 from trunk to my branch, but only
r33301-33923,33925-3396to win32_crypto.c, the latter needs r33924
too." Of course in doing so the user violated the reintegrate
workflow, maybe they reverse merged r33924 from trunk to
win32_crypto.c, but at least we give them an idea of where to look for
the problem.

Notice that only the subtree paths that differ from the root of the
source are displayed. In the above example there are many other paths
in branches/issue-3067-deleted-subtrees that have explicit mergeinfo,
but they all show that r33301-33960 have been merged from trunk. Only
the branches/issue-3067-deleted-subtrees/subversion/libsvn_subr/win32_crypto.c
subtree differs. Notice also that all mergeinfo from other branches
has been filtered out, only mergeinfo from trunk is shown as that is
all that matters here.

The one thing I dislike about this error is the size to which it can
grow (and become completely useless) if the reintegrate source is
vastly out of synch with the target -- see the attached output.

Does this error make sense? Should we keep it? Any suggestions for improvement?


So if anyone familiar with merge tracking, specifically the
reintegrate code, would like to take a look I'd appreciate it.
Alternatively, if you are going to merge a branch back to trunk please
try it with this branch and use --reintegrate. And finally, if you
have any thoughts on the new error message, have at it.



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-05 16:03:29 CET

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.