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

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

From: Paul Burba <ptburba_at_gmail.com>
Date: Wed, 2 Dec 2009 10:18:48 -0500

On Wed, Dec 2, 2009 at 5:20 AM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Paul Burba <ptburba_at_gmail.com> 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 <dev_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe_at_subversion.apache.org>.
Received on 2009-12-02 16:19:17 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.