On Wed, Jul 13, 2011 at 6:43 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> See:
>
> http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording
>
> Sent from my iPhone
>
> On Jul 13, 2011, at 6:29 PM, Peter Samuelson <peter_at_p12n.org> wrote:
>
>>
>> [Greg Stein]
>>> Is there any way that we can remove the svn:mergeinfo property from
>>> those files? I'm not sure if that would be Proper, or if that would
>>> bust something up.
(stefan2: I'm ccing you to draw your attention to some changes you
made in r1067669, r1067674, and r1081136. Could you confirm or
correct my understanding as to what you did? See below).
Hi Greg,
It depends on why the subtree mergeinfo is there in the first place.
Right now on trunk we have the following subtrees with mergeinfo:
(subversion\libsvn_fs_fs\temp_serializer.c):
(subversion\libsvn_fs_fs\temp_serializer.h):
(subversion\include\private\svn_temp_serializer.h):
(subversion\libsvn_subr\svn_temp_serializer.c):
Due to a --record-only merge "from the performance branch as all these
changes are already present in /trunk" in r1081136.
(subversion\libsvn_subr\hash.c):
Due to a --record-only merge in r1144572: "The changes to hash.c were
accidentally committed in r1144565 to the revprop-packing branch as
part of another commit, and subsequently reverted in r1144568.
Therefore this commit also record-only merges r1144568."
(subversion\libsvn_subr\adler32.c):
(subversion\include\private\svn_adler32.h):
Due to a URL-to-WC rename in r1054277
(subversion\include\private\svn_string_private.h):
Due to URL-to-WC rename in r1130548
The first two groups seem legitimate uses of subtree merges,
particularly the first: What happened there was this:
* In r1067669 stefan2 merged some changes from the performance branch to trunk.
* In r1067674 he removed the mergeinfo from the root of trunk that
described a portion of the changes he merged in r1067669 because some
of those changes had "not been merged completely into /trunk. Some
changes in each of these revisions still need to be merged at some
point in the future"
* Lastly, in r1081136 he did a series of --record-only subtree merges
to block the only the portions of r1067669 already merged from the
performance branch.
Awkward to figure out what happened to be sure, but the resulting
subtree mergeinfo is descriptive of what he did.
The last two we could delete without harm, since creating mergeinfo on
the destination of intra-branch moves carries little (if any)
practical benefit (it's just a matter of how to detect 'intra-branch'
moves).
~~~~~
I agree with Peter and his reasons as to why we should keep all of it.
~~~~~
Lastly and probably most importantly, as Mark implies, if a 1.7 client
was used to do this merge there would have been none of this noise in
the first place because no subtree mergeinfo would would have been
updated by the merge (as none of those subtrees were touched by it):
C:\SVN\src-trunk-4>svn --version
svn, version 1.7.0-beta1 (Beta 1)
compiled Jul 13 2011, 17:15:07
Copyright (C) 2011 The Apache Software Foundation.
This software consists of contributions made by many people; see the NOTICE
file for more information.
Subversion is open source software, see http://subversion.apache.org/
The following repository access (RA) modules are available:
* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- handles 'http' scheme
- handles 'https' scheme
C:\SVN\src-trunk-4>svn info
Path: .
Working Copy Root Path: C:\SVN\src-trunk-4
URL: https://svn.apache.org/repos/asf/subversion/trunk
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1146148
Node Kind: directory
Schedule: normal
Last Changed Author: hwright
Last Changed Rev: 1146143
Last Changed Date: 2011-07-13 13:11:42 -0400 (Wed, 13 Jul 2011)
C:\SVN\src-trunk-4>svn merge -c 1146145 ^^/subversion/branches/revprop-packing .
--- Merging r1146145 into '.':
U subversion\libsvn_fs_fs\rep-cache.c
--- Recording mergeinfo for merge of r1146145 into '.':
U .
C:\SVN\src-trunk-4>svn st
M .
M subversion\libsvn_fs_fs\rep-cache.c
Paul
>> They probably aren't needed, but we really should eat our own dogfood.
>> If subtree mergeinfo causes problems (even if only the readability
>> problems of a commit mail with a small diff swamped by meaningless
>> noise), best to address those problems, rather than just try to _not_
>> use this feature that apparently our users wanted.
>>
>> That, or implement Andy's hand-wavy 'newmerge' that punts on subtree
>> merges entirely. (:
>> --
>> Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
>
Received on 2011-07-14 16:47:21 CEST