subversion 1.6.x losing changes on check-in

Question

I'm trying to figure out if this is a known issue with SVN 1.6.x Developer A modifies a file and commits it. Developer B modifies the same file. Tries to commit it and gets told local copy out of date so does an update and then a commit.

However the changes from Developer A are lost so the resulting file only contains the version that Developer B checked in.

We can see this in the logs. It seems to happen when the same file is modified but in different places.

Anyone else experienced this? We've had it happen 4 or 5 times in the past few weeks and we've lost a half day or so each time trying to figure out what's been lost, etc.

We're starting to lose confidence in SVN. Should we be thinking of moving to GIT or Mercurial? Would that sort out this problem?

Answer 1

Is anyone on your team copying files and folders around manually so that the revision info in the .svn folders is no longer correct?

As derobert describes in an answer to a related question, overwriting other users changes is possible if you manually copy your modified files into a newly updated SVN folder:

Here is how the nuke/copy procedure can revert other people's changes:

1. Checkout, get r1;
2. Modify foo.c, giving r1 + changes;
3. Someone else checks in a change to foo.c (you don't know they've done this, of course, and the normal way of checking is broken for you), foo.c in the repo is now r2;
4. You now nuke your repository except foo.c (r1 + changes);
5. You do a checkout, get foo.c r2.
6. You replace foo.c with your copy (r1 + changes). Subversion, however, is unaware of this, and thinks you based your changes on r2, not r1.
7. Checkin, foo.c is now r3, which has just lost the other person's changes in r2.