Re: RFC: Allow no-op merges to modify mergeinfo

Nothing but cheers and +1's here.

Paul Burba wrote:
> 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
>

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand