Why am I getting a bad merge?

[Steven Boswell II <ul...@yahoo.com>]

(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


      

Re: Why am I getting a bad merge?

[Julian Foad <ju...@wandisco.com>]

On Sat, 2010-06-19, Steven Boswell II wrote:
> (I asked this question almost a month ago on the users list, but got
> no response, so now I'm trying the developers list.)

Hi Steven.  I'm sorry to hear you're having difficulty using Subversion.
Please re-post your question to the users list and I very much hope
someone can help you solve it.  (The "dev" list is for discussing the
development of Subversion.)

A small suggestion: sometimes readers are more likely to respond if they
can see a list of the precise commands you ran, followed by the actual
result and the expected result.

Regards,
- Julian

Re: Why am I getting a bad merge?

[Daniel Becroft <dj...@gmail.com>]

On Sun, Jun 20, 2010 at 2:24 AM, Steven Boswell II <ul...@yahoo.com> wrote:
> (I asked this question almost a month ago on the users list, but got no response, so now I'm trying the developers list.)

Developers list is not an escalation point of the users@ list. Moving
back to the users@ list now ...

> 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>

Are you trying to merge on that path explicity, or still merging on
the parent directory?

> 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".

What is the output from the from the following commands:

svn mergeinfo --show-revs merged branch_folder
svn mergeinfo --show-revs merged branch_file

These will tell you (in a more readable format) the revisions that SVN
belive have already been merged.

svn mergeinfo --show-revs eligible branch_folder
svn mergeinfo --show-revs eligible branch_file

These will list the revisions that SVN thinks are available to be
merged. If r37 is not being merged, then it should be listed in one of
the first two commands.

<snipped />