conflicts where there shouldn't be?

We've recently encountered an alarming problem with subversion and
wonder if anyone has experienced this and can help us avoid this kind of
problem in the future.

We decided we needed a branch during a period where two developers, in
particular, had outstanding modifications (not yet checked in) in their
working copy of the "trunk". One of those developers created the branch
by using the command:

            svn copy <working-copy> <url-to-new-branch>

The documentation suggests that if there are outstanding changes in
<working-copy> that subversion will do two things:

1. It will make the new branch correspond to the repository
versions associated with the url of working-copy (in other words, it
will do the equivalent of "svn copy <url-of-trunk> <url-of-branch>")

2. Check in the outstanding modifications on the branch.

It suggests that this is a shortcut for:

            svn copy <url-of-trunk> <url-to-new-branch>

            svn switch <url-to-new-branch>

            svn commit

Once this was done, development continued for the group on the
<url-to-new-branch>. Everything was fine until the time that we wanted
to merge the branch to the trunk.

We did an:

            svn co <url-of-trunk>

            svn merge -r NNN:HEAD <url-of-new-branch>

The result of the above were TONS of conflicts. When we checked many of
the conflicts were for files that HAD NOT been modified on the trunk.
We can find no reason for the conflicts. We underwent a very elaborate
recovery process where we checked each file for modifications on the
trunk, and if there had been none, we resolved the conflict with the
copy from the branch. For the files with changes on the trunk, we did
manual merges. We do not understand why what we believed to be very
basic functionality of svn failed for us.

This was actually the first problem we had of this nature. The second
problem is detailed below (should not be confused with first problem
above, yet is probably very similar). This second problem occurred in a
totally different repository.

We had a trunk and a developer with outstanding changes to that trunk
which were NOT checked in. We intended to retire this trunk and create
a brand new trunk - but we wanted to preserve this old trunk because
there were some changes in that tree that we needed to retrieve and
leverage in the new trunk.

So we did a:

            svn copy <url-of-trunk> <url-of-trunk.old>

            svn rm <url-of-trunk>

            svn mkdir <url-of-trunk>

(Our administrator accidentally used "svn copy" rather than "svn move"
and hence the "copy and delete", above).

Then, a new tree was checked into to <url-of-vendor-xxx> and then the
"trunk" was made to be a copy of that vendor release.

            svn copy <url-of-vendor-xxx> <url-of-trunk>

So, theoretically, we had a new "trunk" to start with. And we had saved
a copy of the "old trunk" under <url-of-trunk.old>

We realized that we really wanted the outstanding changes on one
developer's machine saved away under <url-of-trunk.old>

So, he did:

            svn switch <url-of-trunk.old> (because his repository
url was pointing at the moved (copy, rm, mkdir) trunk).

We expected that operation to result in no conflicts because the
<url-of-trunk.old> should have reflected exactly what this user had
checked out and subsequently modified. There were NO OTHER changes
checked into to <url-of-trunk.old> since the "move".

Yet, we received hundreds of merge conflicts. When we inspected the
merge conflicts, none of the conflicted files had, in fact, been changed
on "trunk.old". There should have been no conflicts. However, we
noticed that the conflicts occurred for files that had changes checked
into <url-of-vendor-xxx> and subsequently copied to <url-of-trunk>.

So, both of the above situations resulted in conflicts that shouldn't
have occurred (at least according to our undertstanding of subversion).
Whether or not any changes occurred in OTHER repository directories
should have had no impact on svn operations on the target repository
directories.

Can someone explain what happened and why?

We are using subversion clients on cygwin/windows of version:

            $ svn --version

svn, version 1.3.2 (r19776)

            compiled Jul 14 2006, 22:16:08

Our repository is accessed using svn+ssh and lives on a SuSE linux box.
The version of subversion on that machine is:

            $ svn --version

svn, version 1.2.3 (r15833)

            compiled Sep 13 2005, 02:25:01

Any help would be greatly appreciated. Our confidence in subversion has
decreased dramatically since these two occurrences. -- Eric
Received on Thu Dec 14 21:47:10 2006