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