Why am I getting a bad merge?

I recently began using Subversion to track a project at the new company where I work.  We've been using it for a few weeks, and our database has just over 60 commits to it now.

I created a "release" branch of the project at revision 36, and have been doing heavy development in the trunk, merging only the bug fixes into the branch.  It now looks like my trunk changes are fine, and I wanted to merge them into the release branch, but that's where things went wrong.  Most of the files were fine, but one file missed a very large change!

In the branch, that file had a change at revision 62, and as mentioned above, the branch was created in revision 36.  In the trunk, that file was modified in revisions 61, 59, 37, 23, and points earlier.  The single merge of that file into the branch was done with "svn merge -r61:62 <path>", run on the parent directory.  When I try to merge the trunk version of that file into the branch, I get:

--- Merging r47 through r62 into '<filename>':
U          <filename>

As you can see, it skips the change to the file made in revision 37!  Specifying "-r36:62" in the command line gives the same result.  I'm not even sure why it's mentioning revision 47, because the file wasn't changed then.

"svn propget svn:mergeinfo --depth infinity <branch file>" shows nothing, not even the merge from "-r61:62".

In addition, I can't seem to produce an accurate dump to show others for debugging purposes -- I try "svnadmin dump <repo> | svndumpfilter --drop-empty-revs include <trunk path> <branch path> > repodump.txt", but the only revision shown for the branch path is 62...there's no mention of the creation of the branch back in revision 36, so reconstructing the database fails -- the branch path never gets created.  (And yes, I created all the parent directories directly...I dug around the mailing-list archives and found out that step was necessary for filtered dumps.)

There's another problem, which is that some files I deleted in the trunk showed up in the merged branch as conflicts, but that's a separate problem, and at least that problem drew attention to itself -- the bad merge I described above had to be found by reading over all the changes one by one.

Does anyone have any idea what could have gone wrong?  This seems like an out-and-out bug in Subversion.

I'm running CollabNetSubversion-server-1.6.11-3.win32 on a machine running Windows Server 2008, and CollabNetSubversion-client-1.6.11-3.win32 and TortoiseSVN-1.6.8.19260-win32-svn-1.6.11 on a laptop running Windows Vista.  Most of my commits were done with TortoiseSVN, but all my merges were done with the command-line client.

Thanks in advance for any insight into these problems!  I'm trying to sell the concept of version control (and open-source software) to a team with some rather backwards development processes, and this glitch isn't helping my case.

Steven Boswell
Received on 2010-05-25 16:36:54 CEST