Well... was it SVN that blew away the code... or was it you? For example, you might have updated your working copy... then copied in an older version to your working copy and committed it. This would "blow away" all that code. But, it wasn't really svn that did it.. it was you.
IF you compare the rev that was prior to your check in, and yours... do a blame on it... you will probably see that you blew away all the code. It is only going to let you commit a file if there have been no changes to it in the repository since you last updated. For example, if you update your WC, and I check in an update to FileA.... if you try to commit something to FileA it won't let you. It will tell you that you need to update first. When you update it will merge my changes into your file A. But, it can't know if you are committing the correct thing. BOb From: Steve Calamia [mailto:stephen.cala...@wpni.com] Sent: Tuesday, March 16, 2010 1:25 PM To: users@subversion.apache.org Subject: Changed files overwritten with old version upon commit I have a strange scenario: We are two developers that use an SVN repository to coordinate code releases. I pull down the repository daily, often several times a day. I recently committed to the server and it "blew away" my coworker's changes, without any sort of conflict. Like not a few lines of code, but a hundred or so. This has happened twice now on two separate occasions both recent. Here's the catch: I actually saw in my local dev some of the code that got blown away by my most recent commit. So the code must have been in my local repository prior to committing. Any way to check this? Local logs or anything? I am using version 1.6.5 and the svn server is on Unfuddle. Any ideas how or why it would have overwritten the file with an older version upon committing? Also, any ideas where the problem may lay: my svn client, coworker's svn client, or Unfuddle? I'm happy to provide any additional details anyone thinks may be helpful. MUCH thanks in advance, Steve Calamia
