With a note of panic, I received the message that svn update had thrown away a developer’s changes. He had attached a log showing the commands he had issued. Sure enough, instead of seeing a merge, the file was updated and his changes were gone. The only thing not in the log I wish was there was a svn status command.

I was concerned but not overly worried. Since we converted from CVS to Subversion, there had not been any major issues. No one else had reported these problems. Obviously, if this were a bug in Subversion, it would be all over the web. There was something here that was missing in the description. I needed more details. I arranged a meeting to investigate.

What we discovered was enlightening and led us to a better understanding of how Subversion works. After discussing the situation, below is what we discovered had happened. For the purpose of the description, “Developer A” is the person who reported the issue. “Developer B” is another person on the team.

Developer A and Developer B’s working copies are both at revision N.

Developer A commits a change. (His working copy is now at revision N+1.)

Developer A and Developer B discuss and agree that the change needs to be rolled back.

(It is a little fuzzy here what happened. However, the essentials are correct)

Developer A “undoes” his change manually but does not commit the change. (His working copy is still a revision N+1.)

Developer B updates his working copy (now at revision N+1). Developer B issues the reverse merge command to undo the change introduced by Developer A. Developer B commits the change. (His working copy and the repository are now at N+2.)

(Time passes…)

Developer A and Developer B discuss and realize that the original change (committed at revision N+1) does need to be made.

(Here is where the confusion occured)

Developer B (whose working copy is still at revision N+1 while the repository is at N+2) starts to work on the change. Without updating his working copy, he reintroduces the change manually and does a svn update

At this point, svn “throws away” Developer A’s change.

If you are familiar with Subversion, you already know why. If Developer A had issued the following commands, he would see what happened:

(Working copy at revision N.)

Make changes.

svn commit

(Working copy at revision N+1.)

Manually undo the changes.

svn status filename
(The command indicates that filename has changed from the base revision – N+1)

Manually redo changes.

svn status filename
(Indicates no change in the file. Even though it has been changed twice since the last commit, it is now identical to the file at the time of the last commit in this working copy.)

svn update filename
(Subversion checks to see if the file is different from the base revision – N+1. It isn’t. No merging of changes need to be made. Go ahead and update the file to the state it exists at revision N+2 thus “throwing away” the changes the developer had introduced.