[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: Fri, 4 Dec 2009 09:53:10 -0500

On Wed, Dec 2, 2009 at 10:41 AM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Paul Burba <ptburba_at_gmail.com> writes:
>
>>> 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.
>
> I could ask why normal merge produces notification, after all the user
> has to check status and diff to ensure that the merge got applied
> correctly. Does that mean the normal merge notification is of no use?

Point taken.

> The obvious case where record-only notifications help is when the
> merge doesn't change anything, because I got the wrong source URL or
> revision. If I'm expecting to see a change and I get no notification
> then I know I made a mistake.

Ditto.

>> 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
>
> I was thinking just the U line.

I think a "record only" header is necessary. Now that --record-only
merges may apply svn:mergeinfo diffs, we might also see traditional
merge notification headers. Without a special header it looks like
all notifications are related to the diff, which IMO is quite
confusing.

For example, we have a WC merge target with no pre-existing mergeinfo:

>svn pg svn:mergeinfo -vR A2\D\G

We want to merge a rev from some other branch that includes
svn:mergeinfo property changes:

>svn diff ^^/A_COPY/D/G -c11
  Index: rho
  ===================================================================
  --- rho (revision 10)
  +++ rho (revision 11)
  @@ -1 +1 @@
  -This is the file 'rho'.
  +New content
  \ No newline at end of file

  Property changes on: rho
  ___________________________________________________________________
  Added: svn:mergeinfo
     Merged /A/D/G/rho:r4

Currently in trunk(@887205) the merge produces a notification only for
the mergeinfo change:

>svn merge --record-only -c11 ^^/A_COPY/D/G A2\D\G
  --- Merging r11 into 'A2\D\G':
   U A2\D\G\rho

But of course the --record-only logic recorded mergeinfo *describing*
the merge on the target too:

>svn st
   M A2\D\G
   M A2\D\G\rho

>svn pg svn:mergeinfo -vR A2\D\G
  Properties on 'A2\D\G\rho':
    svn:mergeinfo
      /A/D/G/rho:4
      /A_COPY/D/G/rho:11
  Properties on 'A2\D\G':
    svn:mergeinfo
      /A_COPY/D/G:11

If we add notifications for mergeinfo changes describing the merge it
would look something like this...

>svn merge --record-only -c11 ^^/A_COPY/D/G A2\D\G
  --- Merging r11 into 'A2\D\G':
   U A2\D\G\rho
   U A2\D\G

...Which makes it appear that the change to A2/D/G was part of the
diff. I think it is a lot clearer if the mergeinfo changes made to
describe the merge have their own special header:

>svn merge --record-only -c11 ^^/A_COPY/D/G A2\D\G
  --- Merging r11 into 'A2\D\G':
   U A2\D\G\rho
  --- Recording mergeinfo for r11 into 'A2\D\G':
   U A2\D\G

This isn't a big deal in simple examples, but if there are mergeinfo
diffs applied to many subtrees *and* many subtrees with pre-existing
mergeinfo, then things get quite ugly.

Paul

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

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-04 15:53:24 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.