Re: valgrind UMRs in "svn merge --record-only"

On Wed, Dec 2, 2009 at 5:20 AM, Philip Martin
<[email protected]> wrote:
> Paul Burba <[email protected]> writes:
>
>>> The --record-only merge produces no notifications at all.  I need to
>>> check status before and after to determine whether it did anything at
>>> all.  Perhaps --record-only merges should produce notification for
>>> each directory where the svn:mergeinfo gets modified?

A minor point, but I assume you meant "path", rather than "directory",
since mergeinfo can exist on files as well.

>> Yes, it has always been the case that mergeinfo changes made as part
>> of the 'describing the merge' are silent, for both "regular" merges
>> and --record-only merges.  It wasn't in the original design, but was
>> discussed during development.  IIRC the thinking that this would
>> reduce confusion, but I can't find the thread.  Regardless of the
>> original reasoning, I don't see much evidence that many users
>> considered this a problem, while I see *lot's* of evidence that they
>> the more mergeinfo changes they are exposed to, the more confused they
>> get, i.e. http://svn.haxx.se/dev/archive-2009-08/0045.shtml.
>
> Your link show lots of users complaining about merge producing too
> much mergeinfo but I didn't see any complaints about --record-only
> producing too much notification; none of the links mentioned
> --record-only at all.

Sorry, I did not mean to imply that those links had anything to do
with --record-only in particular, rather that they illustrate the
frustration and confusion that mergeinfo has caused in general and
that we should proceed cautiously with "obvious" improvements in that
space.

> I agree that it's reasonable for a normal merge to suppress
> notifications about mergeinfo,

Ah, I got it in my head that you were suggesting we produce
notifications for mergeinfo on *all* merges...

> but I think it's a mistake to do the
> same for record-only merges.

...when you were clearly suggesting producing notifications for
mergeinfo changes only during --record-only merges.

> How is the user supposed to have any
> confidence that they have run the command correctly,

How would a notification really help them know they ran the command
*correctly*?  Like any merge, choose the wrong source, the wrong
target, the wrong revision, you get the wrong result.  I don't see how
improved notifications avoid the need to check svn status, diff,
and/or propget svn:mergeinfo after the merge, to see if the result is
what was expected.  Admittedly --record-only merges are particularly
problematic because there are no text or tree conflicts to alert us
that we might have screwed up, but I still don't see how notifications
help users much in confirming correctness.

Possibly I am thinking of too simplistic a notification.  I assume the
notification would be something like this in the simple case (i.e. no
pre-existing subtree mergeinfo, no incoming mergeinfo diffs):

  svn merge ^^/trunk branches\b1.0  -c357 --record-only
  --- Recording mergeinfo for r357 into 'branches\b1.0':
   U    branches\b1.0

> or indeed that
> the command had any effect at all, if it produces no notification?
> The whole point of record-only is to update mergeinfo, supressing the
> notifications just seems really odd.

All of my hedging aside, I'm not opposed to --record-only
notifications, but I don't see any evidence that users are confused by
the lack of output.  If there is confusion and/or if we all think this
is an improvement I'm happy to get this into 1.7.

Paul

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2426370

Please start new threads on the <[email protected]> mailing list.
To subscribe to the new list, send an empty e-mail to <[email protected]>.