On Thu, Feb 5, 2009 at 8:26 PM, Michael Cowperthwaite
<mikec_at_lathropengineering.com> wrote:
> On 05-Feb-2009 4:41 pm, Mark Phippard wrote:
>> 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.
>
> Thank you, Mark. While examining this, I remembered that one
> subdirectory of the root had been switched from the branch (where I'm
> working) to the trunk, and I'd forgotten to switch back once the trunk
> changes behind that switch had been merged to the branch.
>
> I reverted, switched that directory back, and re-merged, and got the
> expected results of no property changes except the root and the one
> oddball file.
I am glad you made the connection. I should have thought to mention
switch, in addition to sparse directions in my reply.
In the CollabNet Merge client we check for these things before doing
merges to help avoid those problems. I believe the AnkhSVN merge
wizard does the same.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1109937
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-06 02:34:40 CET