(I asked this question almost a month ago on the users list, but got no
response, so now I'm trying the developers list.)
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
