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

Re: [RFC/PATCH] Allow merge to apply only svn:mergeinfo diffs

From: Paul Burba <ptburba_at_gmail.com>
Date: Thu, 22 Oct 2009 13:17:39 -0400

On Mon, Oct 19, 2009 at 1:39 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Mon, Sep 28, 2009 at 3:32 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>> On Mon, Sep 28, 2009 at 2:16 PM, Paul Burba <ptburba_at_gmail.com> wrote:
>>
>>> 1) Any problem with implementing something like this?
>>>
>>> 2) If the general idea is ok:
>>>
>>> 2a) Should any notifications be shown?  The existing patch shows
>>> notifications for paths with mergeinfo changes, but I'm not sure how
>>> useful these are.  Perhaps, like --record-only, there should be no
>>> notifications?
>>
>> I like seeing notifications.  I do not see what it hurts and it can
>> help scripts and tools.  In Subclipse, as an example, the
>> notifications lets us know what paths have been changed so that we can
>> refresh their status.
>>
>>> 2b) Should this be a new option to svn merge as in the patch?  Or
>>> should it be the default behavior of --record-only?  If the latter
>>> then we need to consider that this will slow --record-only merges down
>>> compared with today's simple-no-editor-drive approach.  Though I don't
>>> think the performance hit will be too severe, since a lot of the
>>> performance problems related to merge (Issue #3443, implicit mergeinfo
>>> lookups (r36509), etc.) are fixed on trunk or don't apply here (e.g.
>>> multiple editor drives during a singe merge).  Or maybe there is some
>>> other solution, --record-only = ARG, where ARG is two choices, one
>>> representing the old simple way, one the new restricted editor drive.
>>>
>>> Any thoughts are appreciated, thanks,
>>
>> It is probably opening a can of worms we are not ready to deal with,
>> but what about using --block ?  As your own description explains, that
>> is exactly the kind of scenario where this is needed.
>>
>> The big problem I see ( can of worms ) is that eventually people want
>> to see what they have blocked and so this would not be enough.
>
> Mark and I talked about this recently and came to the conclusion that
> making the proposed behavior the *default* for --record-only is
> probably the best approach.  Merge tracking is complicated enough
> without introducing new options and, as described above, the
> performance price for this change should be reasonable.
>
> The attached patch makes --record-only apply only svn:mergeinfo diffs
> by default.  It shows notifications for any path updated (unlike
> --record-only's current behavior which never shows any notifications).
>  It also adds a new merge test to demonstrate the new functionality.
>
> Any thoughts, questions, and/or objections to this change let me know.
>  Barring any objections I'll be committing this sometime this week.

Committed r40190. Only differences between that and the previously
posted patch are new help text on the --record-only option and a doc
string tweak for svn_client_merge3().

> Paul
>
> [[[
> Let --record-only merges apply svn:mergeinfo diffs.
>
> See http://svn.haxx.se/dev/archive-2009-09/0520.shtml for discussion.
>
> * subversion/libsvn_client/merge.c
>  (merge_props_changed): Only allow svn:mergeinfo prop changes to be changed.
>
>  (merge_file_changed,
>   merge_file_added,
>   merge_file_deleted,
>   merge_dir_added,
>   merge_dir_deleted):
>   Exit early if this is a --record-only merge.
>
>  (notification_receiver): If performing a --record-only merge, limit
>   notifications to mergeinfo changes.
>
>  (do_directory_merge): Actually drive the editor for --record-only merges.
>
> * subversion/tests/cmdline/merge_tests.py
>  (record_only_merge): New test.
>
>  (test_list): Add record_only_merge.
> ]]]
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410319
Received on 2009-10-22 19:18:09 CEST

This is an archived mail posted to the Subversion Dev mailing list.