On Thu, Dec 10, 2009 at 8:53 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Mark Phippard wrote:
>> On Thu, Dec 10, 2009 at 5:30 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
>> > 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.
>
> Ah, thanks, I hadn't remembered that change, and that makes a huge
> difference. Great. It's fine to issue lots of subtree mergeinfo
> notifications if lots of files were touched by the merge.
>
> +1 to adding the notifications as proposed.
>
> - Julian
I committed this enhancement in r902509.
A few things to note:
1) In my example at the start of this thread I used an ' A'
notification to denote the addition of a mergeinfo property. That
does not agree with how we notify property additions in other cases;
we use ' U' for the addition, deletion, or modification of a property
and ' G' for a change to a locally modified property. My patch sticks
to those conventions.
2) I added a separate header when mergeinfo is elided vs. recorded to
describe a merge, e.g.:
>svn pg svn:mergeinfo -vR A_COPY_2
Properties on 'A_COPY_2\D':
svn:mergeinfo
/A/D:5
>svn merge ^^/A A_COPY_2 -c5
--- Recording mergeinfo for merge of r5 into 'A_COPY_2':
U A_COPY_2
--- Eliding mergeinfo from 'A_COPY_2\D':
U A_COPY_2\D
>svn diff
Property changes on: A_COPY_2
___________________________________________________________________
Added: svn:mergeinfo
Merged /A:r5
Property changes on: A_COPY_2\D
___________________________________________________________________
Deleted: svn:mergeinfo
Reverse-merged /A/D:r5
3) There are still some mergeinfo updates that we don't notify. For
example, when a subtree has non-inheritable mergeinfo, the subtree's
immediate children without explicit mergeinfo get (possibly temporary)
explicit mergeinfo set which reflects the inheritable portion of it's
parent. Ultimately this is reported (or removed silently) at the end
of the merge, so I've kept these updates quiet; notifying of these
changes would IMHO cross the line between "informative" and "confusing
noise".
4) --dry-run merges currently do *not* produce the new notifications.
It doesn't make any sense to me that they should, but I'm open to
arguments to the contrary.
Paul
Received on 2010-01-24 00:50:25 CET