On Thu, Dec 10, 2009 at 5:30 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Stefan Sperling wrote:
>> On Wed, Dec 09, 2009 at 04:40:27PM -0500, Paul Burba wrote:
>> > # Instead of silence on the type 2 mergeinfo changes,
>> > # what I am proposing is something like this:
>> >
>> > >svn merge ^^/trunk . -c35049
>> > --- Merging r35049 into 'subversion\tests':
>> > U subversion\tests\cmdline\svntest\main.py
>> > --- Recording mergeinfo for merge of r35049 into '.':
>> > A .
>> > G subversion
>> > G subversion\tests
>> >
>> > Specifically, the special header (for a single rev)
>> >
>> > --- Recording mergeinfo for merge of rX into 'path':
>> >
>> > or (for multiple revisions)
>> >
>> > --- Recording mergeinfo for merge of rM through rN into 'path':
>> >
>> > would be printed after all type 1 notifications. Then all the type 2
>> > notifications would be grouped together.
>>
>> I like your proposal.
>> I think it's a good idea to always tell users what is happening with
>> mergeinfo. The UI should show mergeinfo changes wherever possible.
>> It's important that users do not overlook mergeinfo changes and end
>> up not committing them.
>
> True, but also we must cautiously balance the helpfulness of
> notifications against the possibility for a mass of uninteresting
> mergeinfo notifications to overwhelm the user and make it hard to see
> the interesting changes. Some users have hundreds of nodes with subtree
> mergeinfo.
>
> It is worth considering printing an abbreviated notification.
Given that Paul's proposal calls for adding a new section to the
notification process to show the paths that mergeinfo is applied to,
don't you think he accomplishes this goal? Even if the notifications
are perceived as overwhelming, they are still segregated to their own
area where you can easily ignore them.
In addition, the trunk code no longer updates subtrees with mergeinfo
unless they are modified by the merge. So there really should not be
too much extra noise.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2009-12-10 14:43:30 CET