I just described my experience inadvertently creating an inconsistent state between two working copies of the same branch while trying to resolve tree conflicts over at: http://stackoverflow.com/questions/767763/svn-how-to-resolve-new-tree-conflicts-when-file-is-added-on-two-branches/7100512#7100512 To make this more self-contained, I'll repeat the key text here:
(1): I had added some files while working on my initial branch, branch1; (2) I created a new branch, branch2 for further development, branching it off from the trunk and then merging in my changes from branch1 (3) A co-worker had copied my mods from branch1 to his own branch, added further mods, and then merged back to the trunk; (4) I now wanted to merge the latest changes from trunk into my current working branch, branch2. This is with svn 1.6.17. The merge had tree conflicts with the new files, and I wanted the new version from the trunk where they differed, so from a clean copy of branch2, I did an svn delete of the conflicting files, committed these branch2 changes (thus creating a temporary version of branch2 without the files in question), and then did my merge from the trunk. I did this because I wanted the history to match the trunk version so that I wouldn't have more problems later when trying to merge back to trunk. Merge went fine, I got the trunk version of the files, svn st shows all ok, and then I hit more tree conflicts while trying to commit the changes, between the delete I had done earlier and the add from the merge. Did an svn resolve of the conflicts in favor of my working copy (which now had the trunk version of the files), and got it to commit. All should be good, right? Well, no. An update of another copy of branch2 resulted in the old version of the files (pre-trunk merge). So now I have two different working copies of branch2, supposedly updated to the same version, with two different versions of the files, and both insisting that they are fully up to date! Checking out a clean copy of branch2 resulted in the old (pre-trunk) version of the files. I manually update these to the trunk version and commit the changes, go back to my first working copy (from which I had submitted the trunk changes originally), try to update it, and now get a checksum error on the files in question. Blow the directory in question away, get a new version via update, and finally I have what should be a good version of branch2 with the trunk changes. I hope. Further notes: Our standard working practice is that all merges except merges from the trunk are done with a specific range of revision numbers, getting the relevant revisions via svn log -stop-on-copy on the appropriate branch. This applied to my merge from branch1 to branch2, my co-worker's merge from my branch1 to his branch, and his merge from his branch back to the trunk, but not to my merges from the trunk described above. I'm not sure if this matters, but I report it here in case it makes a difference when trying to reproduce the problem. Most of the svn operations took place on Windows 7 Pro from a Cygwin command line, but the other copy of branch2 that I was comparing to was on a Linux VM. Dave Wallace
