[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: Tue, 1 Dec 2009 10:31:59 -0500

On Tue, Dec 1, 2009 at 5:17 AM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Paul Burba <ptburba_at_gmail.com> writes:
>
>> Those 'if (merge_b->record_only)' early exits were added in r880264
>> which implemented the change that allows --record-only merges to apply
>> only svn:mergeinfo diffs, see
>> http://svn.haxx.se/dev/archive-2009-09/0520.shtml.
>
> Yes, I'd already found that from the log message on the revision that
> introduced the change.  In that email the double carets, ^^, are
> single carets for Subversion escaped for the windows shell, is that
> correct?

Hi Philip,

IIUC the ^ became the escape character starting with XP.

>> You are correct about the the comment 'We are only applying mergeinfo
>> changes to existing paths', as regards merge_dir_added (and
>> merge_file_added); since we are applying only mergeinfo diffs we do
>> not want to actually add any files/dirs.  Unfortunately I used the
>> same comment for merge_file_changed, merge_file_deleted, and
>> merge_dir_deleted, which is quite wrong.  The comment should
>> universally be changed to:
>>
>>   /* Easy out: We are only applying mergeinfo differences. */
>>
>> Is that any clearer?
>
> I've been thinking about it a bit more, let's see if I've got this
> right.  Merge is an URL-to-URL diff that gets applied to the working
> copy, followed by some property modifications to record the merge.  (I
> say "followed by" although there is no requirement for them to be
> sequential, they are done in parallel.)  The URL-to-URL diff consists
> of adds, updates and deletes and these form a conceptually different
> set of modifications to the subsequent modifications that record the
> merge.

That is mostly correct, mergeinfo can arise from 'applying the diff'
or from 'describing the merge'. I say 'mostly' because there is a
requirement that the mergeinfo recorded to describe the merge be done
after the diff is applied; this is when there is subtree mergeinfo
involved. In 1.7 we no longer 'describe the merge' on a subtree with
pre-existing mergeinfo if that subtree was not affected when we
applied the diff, but we don't know whether it was affected or not
until we are done with all editor drives for a given merge source.

> The URL-to-URL diff might even transfer some svn:mergeinfo
> properties from the merge source to working copy but that is still
> separate from the subsequent modifications to record the merge.

Yes, in those cases svn:mergeinfo is treated like any other versioned property.

> When it comes to recording the merge, there will never be any need to
> set or modify the svn:mergeinfo property on any path that is added or
> deleted by the merge.  Merge information only ever needs to be
> recorded in paths exist both before and after the URL-to-URL diff.  So
> in the editor callbacks for added or deleted items we know that no
> merge recording needs to be done below the item.
>
> Is that correct?

That is correct for deleted paths and in most common use cases it is
also true for added paths. There are some edge cases where an added
path will have mergeinfo, see issue #2829, particularly
http://subversion.tigris.org/issues/show_bug.cgi?id=2829#desc14. Also
see libsvn_client/merge.c:record_mergeinfo_for_added_subtrees().

> Another thing I've noticed is that merge doesn't produce notifications
> when it is modifying svn:mergeinfo.  I suppose that was a deliberate
> decision to make merge tracking less obtrusive, but it does mean that
> --record-only merges are alarmingly silent:
>
> rm -rf repo wc
> svnadmin create repo
> svn mkdir -mm file://`pwd`/repo/T
> svn mkdir -mm file://`pwd`/repo/T/foo
> svn cp -r1 -mm file://`pwd`/repo/T file://`pwd`/repo/B
> svn co file://`pwd`/repo/B wc
> svn merge ^/T wc
> svn pd svn:mergeinfo wc
> svn merge --record-only ^/T wc
>
> 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?

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.

Paul

P.S. The tests passed last night for the patch I posted earlier in
this thread. I committed the patch in r885796.

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

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-01 16:32:38 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.