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