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.
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=2409057
Received on 2009-10-19 19:40:09 CEST