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

Yet more problems with tree conflicts

From: Sean E. Russell <sean.russell_at_trueposition.com>
Date: Mon, 22 Jun 2009 18:59:40 -0400

Sorry for the multipart HTML; there's formatting in here I'd like to

I'm getting false conflicts on merging a branch back into the branch
from which it was branched (nice, huh?) I can't provide access to this
repository, and since I'm under a deadline, I'm going to fix this by
brute force. However, I may file a bug about it (it may be moot; the
company I work for is leaning towards migrating to ClearCase), unless
somebody here thinks I shouldn't. We do nightly hot backups of the
repo, so I can probably reproduce this situation if somebody wants more
debugging information, but (as I said) I'm afraid that I can't provide
access to the repository, or dumps of it.

SVN 1.6.3 on both the client and the server.

dx325002tp% svn log -v --stop-on-copy
| grep GuiCarrierCellsiteSectorAntennaEditors.java

Note that there's only a single version of that file on the the target
branch; also, note where it came from.

Now, I check out /branches/R28.0-BRANCH, and try to merge from R12-PRFix
back into that branch. I can't reintegrate, because we occasionally
merge individual changes between branches, which confuses --reintegrate.

$ svn co http://nightrider/repos/scout/branches/R28.0-BRANCH
$ cd R28.0-BRANCH
$ svn log -v -r 9615 http://nightrider/repos/scout/branches/R12-PRFix
r9615 | skumar | 2009-03-06 17:54:19 -0500 (Fri, 06 Mar 2009) | 3 lines
Changed paths:
   A /branches/R12-PRFix (from /branches/R28.0-BRANCH:9614)

Branch for Legacy PR's fixes in R12. (see
$ svn merge -r 9614:HEAD http://nightrider/repos/scout/branches/R12-PRFix
Conflict discovered in
Select: (p) postpone, (df) diff-full, (e) edit,
        (mc) mine-conflict, (tc) theirs-conflict,
        (s) show all options: ^Csvn: Caught signal
svn: Error reading spooled REPORT request response
dx325002tp% svn stat
> local obstruction, incoming add upon merge

The file was created in branch A, merged to branch B, and then branch B
was merged back into branch A. And SVN claims that there's a tree
conflict on the file which wasn't ever changed in branch B.
Specifically, these files were *not* created on any other branch but A,
so it shouldn't be possible to get conflicts on them. Notice that the
file didn't change on either branch after it was merged to B:

dx325002tp% svn log -l 1

r10251 | apavlin | 2009-06-16 11:17:50 -0400 (Tue, 16 Jun 2009) | 7 lines

Delivery of DAS branch to R28.0-BRANCH integration branch.

dx325002tp% svn log --stop-on-copy
r10265 | apavlin | 2009-06-18 13:11:32 -0400 (Thu, 18 Jun 2009) | 5 lines

Rebasing the R12-PRFix branch from R28.0-BRANCH, bringing in the DAS code.

This happens for every single file that was added on branch A and merged
to branch B. There are other changes on branch B, but never on any of
these files. The results are the same with a plain "svn merge

Additionally, although possibly unrelated, SVN isn't merging files
correctly. SVN says that files have been merged, but when diffing the
resulting files, the changes from the other branch aren't always brought
in. Consider:

$ svn annotate
 10251 apavlin
if(!cgi.internalDasGroupId.isNull && cgi.internalDasGroupId.value > 0){
 10251 apavlin label = new JLabel(" DAS
Group ID="+ cgi.internalDasGroupId.value, JLabel.LEFT);
 10251 apavlin label.addMouseListener(this);
 10251 apavlin }
 10251 apavlin contentPane.add(label);

The lines were changed in version 10251; they were removed in the
R12-PRFix branch in 10271 (annotate isn't helpful in this case). The
"rebase" of the PRFix branch occurred in 10265, so the removal of these
lines occurred* after* the rebase. However, after the merge (where SVN
auto-merged this file with no conflicts), the lines are still present:

diff -r --exclude .svn
< if(!cgi.internalDasGroupId.isNull &&
cgi.internalDasGroupId.value > 0){
< label = new JLabel(" DAS Group ID="+
cgi.internalDasGroupId.value, JLabel.LEFT);
< label.addMouseListener(this);
< }
< contentPane.add(label);

However, other changes in this file were correctly merged.

One of three things is going on:

    * We're using SVN incorrectly. It is possible; all merges are being
      done from the command line, and we could have messed something
      up. If so, we're doing it consistently, because encounter these
      issues across several developers, across several branches. It
      almost always is a merge back down to the parent branch.
    * Our repository is broken, or the metadata is. Again, this is
      possible, but I have no way of checking this. The repository
      looks clean from svnadmin's POV, and we don't have any other
      problems with check-in, check-out. It is just merging giving us
    * Subversion's merging and merge tracking is broken.

If it is the last, I'll file a PR, but I suspect that it is too late for
us; these sorts of issues really scare our QA department.

--- SER

Received on 2009-06-23 07:34:50 CEST

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

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