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

Re: [RFC] Add notifications when mergeinfo is set to describe a merge

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Mon, 25 Jan 2010 14:02:44 +0000

On Sat, 2010-01-23, Paul Burba wrote:
> I committed this enhancement in r902509.

Thanks, Paul.

> 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.

Good.

> 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

Perhaps more detail than the user really needs to know, but OK.

> >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

Ew, describing that diff as a "reverse merge" is ugly. Not related to
this patch, though.

> 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".

Good. I agree.

> 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.

I tend to think the opposite - that a dry run should show me exactly
what is going to happen, in as much detail and accuracy as possible, to
save me the bother of running the merge and then reverting it - but I
don't feel that strongly about it.

- Julian
Received on 2010-01-25 15:03:23 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.