[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Possible svn 1.6 cp bug that leads to tree conflict?

From: Johan Corveleyn <johan.corveleyn_at_uz.kuleuven.ac.be>
Date: Fri, 20 Nov 2009 13:40:12 +0100

> Van: Woon Wai Keen [mailto:doubleukay_at_doubleukay.com]
>
> I found this problem while working with svn 1.6 cp + merge. Basically, a
> circumstance where a branch created with svn cp cannot be merged back to
> trunk despite no changes being made to the branch. I was able to
> reproduce the problem with svn 1.6.0 - 1.6.6, while svn 1.5.7 works.

It's normal that 1.5 doesn't show this problem, as it has no tree conflict detection. So even if there were a genuine tree conflict, 1.5 wouldn't complain, and just do what it thinks should be done (which in this case is probably "the right thing", but this is definitely not guaranteed).

For 1.6, I think I understand what's going on, and I don't think it's a bug.

First, important observation: the way you make your branch is atypical and not recommended. You do an "svn cp" in your working copy, and then commit that action. Instead, you should create the branch on the server (and then update your working copy to pull in the new branch, or check out the branch to a new location):

svn cp file:///$PWD/repo/trunk file:///$PWD/repo/branch

I think that it's because you create your branch by making a copy in your working copy that things are going wrong. See below ...

> To reproduce, run:
>
> svnadmin create repo # create and checkout a repository
> svn co file:///$PWD/repo wc
> cd wc # create trunk, trunk/test, trunk/test/file
> svn mkdir trunk
> svn ci -m ''
> svn mkdir trunk/test
> touch trunk/test/file
> svn add trunk/test/file
> svn ci -m '' # shows adding branch, branch/test

(I assume your comment is meant to say "shows adding test, test/file")

At this point, you have a "mixed-revision" working copy: trunk will still be at revision 1 in your working copy (in which it was committed), while trunk/test and trunk/test/file will be at revision 2. You should be able to verify this by running "svn info" on those items.

I'm not sure how this works out in practice (what the actual semantics are by creating your copy this way), but I'm sure that's the cause of your problem. If you would "svn up" your trunk before creating the copy, I think it will work (similar to your workaround of deleting trunk and updating to get it back again). But anyway, as I said, it's best to never create branches this way, and to always create them directly in the repository.

> svn cp trunk branch # copy trunk to branch
> svn ci -m ''
> svn up
> cd trunk
> svn merge ^/branch . # now merge branch to trunk. this fails with a tree
> conflict
> --- Merging r2 through r3 into '.':
> C test
> Summary of conflicts:
> Tree conflicts: 1

One more thing: if you get a tree conflict, you should always execute "svn info" on the conflicted item, to get more details on the exact nature of the conflict.

HTH
Regards,
Johan

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-11-20 13:41:55 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.