You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pt...@gmail.com> on 2008/03/28 16:11:25 UTC
RFC: Allow no-op merges to modify mergeinfo
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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Allow no-op merges to modify mergeinfo
Posted by "C. Michael Pilato" <cm...@collab.net>.
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@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: RFC: Allow no-op merges to modify mergeinfo
Posted by Julian Foad <ju...@btopenworld.com>.
+1 from me on removing the special case. Special casing like this is just
asking for trouble.
- Julian
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@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
--
http://www.foad.me.uk/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Allow no-op merges to modify mergeinfo
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Mar 28, 2008 at 12:11 PM, Paul Burba <pt...@gmail.com> wrote:
> 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?
I say simplify the code. The alternative is to add yet more code to
the special-case logic. I'd rather see us remove the special case and
get a real 1.5 GA user to make the case for why it is needed. It was
one thing to add it when it seemed like a harmless optimization, but
given this elision issue, it seems worth removing the special-case
code.
+1
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org