Currently if we perform a no-op merge then we don't update the
mergeinfo on the merge target, nor do we allow any subtree mergeinfo
to elide the target. "No-op" here is defined as a merge in which
there are no skips and no changes are merged in. "No changes" might
be because there are no changes in the merge source or it might be
because the merge affects only a subtree of the target but that
subtree already has it's own explicit mergeinfo covering the change
(from a previous subtree merge).
This decision came about from users with nightly build scripts that
were merging everything from a branch but where nothing happened on
the branch since the last time the script ran. In those cases they
would end up with commits of only svn:mergeinfo changes - see
http://subversion.tigris.org/issues/show_bug.cgi?id=2883.
julianf, cmpilato, markphip, and I were just discussing this on IRC
and came to the conclusion that this behavior is incorrect. The two
problems we see are these:
1) Multiple Merges vs. Merge with Multiple Ranges Can Result in
Different Mergeinfo
If we do an operative merge of '-r10:13 SOURCE TARGET' the mergeinfo
for TARGET is updated (or created) to reflect the merge of
'/SOURCE:11-13'. But what if r12 doesn't affect SOURCE? If we do the
above merge as three separate merges:
svn merge -c11 SOURCE TARGET
svn merge -c12 SOURCE TARGET ---> no-op, no mergeinfo set
svn merge -c13 SOURCE TARGET
Then TARGET only gets '/SOURCE:11,13'. So in one case the no-op range
is recorded and in another it is not. We think it should be the same
in both cases and that your choice to do one merge or multiple merges
shouldn't matter.
2) It Thwarts Elision
Starting with the WC TARGET which may or may not have
explicit/inherited mergeinfo. We 'merge -rX:Y SOURCE/trunk/sub_dir
TARGET/sub_dir' and commit. Now TARGET/sub_dir has explicit mergeinfo
on it.
Let's assume -rX:Y in SOURCE affects *only* trunk/sub_dir. Now we
merge 'merge -rX:Y SOURCE/trunk TARGET'. This is a no-op merge
because the affected subtree TARGET/sub_dir has already been merged
to.
If no-op merges were allowed to update mergeinfo, then TARGET would
get mergeinfo set, TARGET/sub_dir would have equivalent mergeinfo, and
the latter would elide to the former, making it much clearer what has
been merged into TARGET. Put another way, for users who need to do
sub-tree merges, this would allow them to later perform one (otherwise
no-op) superset merge to consolidate the explicit mergefino on TARGET
rather than having it spread over multiple subtrees.
~~~~~
Anyway, we all want to remove this functionality and make no-op merges
update the merge target mergeinfo and potentially elide and subtree
mergeinfo to the target. The script writers for whom this is a
problem can write a smarter script no?
Any objections to this?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-28 17:11:45 CET