2008/11/5 Paul Burba <ptburba_at_gmail.com>:
> 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.
> 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.
Why does the part about trunk show up? I find that confusing because
it sounds like it is flagging it as part of the problem and I do not
think you mean to say that.
> 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?
I do not see how we can do anything about the possibly large
differences. As long as the information is correct, I do not see a
problem with it. Is it possible for the error message to describe
what they need to do next? Are there a specific set of revisions that
need to be merged into the "root" to resolve this subtree mergeinfo
I think you should probably merge this to trunk as is. I mainly offer
that last comment as a suggestion for where this could possibly go
I think the error message is fine. Here is an attempt at an alternative:
svn: Reintegrate cannot be used with specified merge source due to
differences in subtree mergeinfo. Here are the differences that were
I do not like this suggestion as is. I am trying to make it more to
the point but do not think I achieved that. I put it out there to
advance the conversation. I repeat that I think this should just go
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:27:33 CET