Sorry for the multipart HTML; there's formatting in here I'd like to
preserve.
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
http://nightrider/repos/scout/branches/R12-PRFix/scout/src/com/trueposition/scout/client/wlsconfigclient/GuiCarrierCellsiteSectorAntennaEditors.java
| grep GuiCarrierCellsiteSectorAntennaEditors.java
A
/branches/R12-PRFix/scout/src/com/trueposition/scout/client/wlsconfigclient/GuiCarrierCellsiteSectorAntennaEditors.java
(from
/branches/R28.0-BRANCH/scout/src/com/trueposition/scout/client/wlsconfigclient/GuiCarrierCellsiteSectorAntennaEditors.java:10253)
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
http://tpwiki/index.php/12.0_Branches#R12-PRFix)
$ svn merge -r 9614:HEAD http://nightrider/repos/scout/branches/R12-PRFix
...
C
scout/src/com/trueposition/scout/client/wlsconfigclient/GuiCarrierCellsiteSectorAntennaEditors.java
C
scout/src/com/trueposition/scout/client/wlsconfigclient/GuiMechanicalSurveyEditors.java
Conflict discovered in
'scout/src/com/trueposition/scout/client/wlsconfigclient/WlsConfigTreeCellRenderer.java'.
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
scout/src/com/trueposition/scout/client/wlsconfigclient/GuiCarrierCellsiteSectorAntennaEditors.java
C
scout/src/com/trueposition/scout/client/wlsconfigclient/GuiCarrierCellsiteSectorAntennaEditors.java
> 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
scout/src/com/trueposition/scout/client/wlsconfigclient/GuiCarrierCellsiteSectorAntennaEditors.java
------------------------------------------------------------------------
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
http://nightrider/repos/scout/branches/R12-PRFix/scout/src/com/trueposition/scout/client/wlsconfigclient/GuiCarrierCellsiteSectorAntennaEditors.java
------------------------------------------------------------------------
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
http://.../branches/R12-PRFix".
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
http://nightrider/repos/scout/branches/R28.0-BRANCH/scout/src/com/trueposition/scout/client/mapcomponent/LVPortPopup.java
...
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
R28.0-BRANCH/scout/src/com/trueposition/scout/client/mapcomponent/LVPortPopup.java
R12-PRFix/scout/src/com/trueposition/scout/client/mapcomponent/LVPortPopup.java
115,119d114
< 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
grief.
* 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
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2364333
Received on 2009-06-23 07:34:50 CEST