On Thu, Feb 5, 2009 at 6:22 PM, Michael Cowperthwaite
<mikec_at_lathropengineering.com> wrote:
> I upgraded last month to Subverson 1.5.5, and today I made the first
> merge since the upgrade. Following what I understand to be best
> practice, even tho the change was to a single file, I merged at the root
> of the working copy.
>
> I was surprised to see every subdirectory under the root marked given
> svn:merginfo. The data just seems to be a subdir-specific variation of
> the root's property -- which is to say, it's redundant. This is, like,
> the opposite of elision, which I read up on in the merge-info article
> before posting. (Re-read, I should say.) Elision, if I understand it
> correctly, should take place during the merge; that is, I don't expect
> checking in to elide the redundancy.
Some of this is right, some not. For example, you are right that
commit is not going to elide the properties. Elision only occurs in a
specific case. Suppose you merge r10 to a subtree, creating mergeinfo
on that subtree. Generally, that mergeinfo now needs to live forever
on that subtree and every subsequent merge needs to record mergeinfo
and keep it updated. Elision can occur if you were to later merge r10
into a parent folder (perhaps because you merge all unmerged revisions
into the parent). In that scenario, elision will notice that the
subtree now has all of the same mergeinfo as the parent and can remove
it.
> There is a single file (not in the directory with the modified file)
> which has its own mergeinfo property; prior to the merge, none of the
> subdirectories had mergeinfo, and now they all do.
>
> Is this expected? By design or bug?
My guess is that it is by design. It would help to understand the
scenario more including the before and after mergeinfo. Also, there
are other things that could do this. For example, if you merge into a
"sparse" working copy that is not checked out depth=infinite than it
has to create "non-inheritable" mergeinfo on all of the locations in
your working copy, so that someone else that is merging into a
complete working copy would correctly know that the paths you did not
have do not have those revisions. This is fairly easy to tell by
looking at the mergeinfo property will contain * on those revisions.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1109794
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-06 01:42:42 CET