On Feb 23, 2012, at 08:57, Gary Weinfurther wrote: > I have a team of about seven people, both on Macs and PCs. Within the last > couple of weeks, we have been experiencing frequent occurrences of lost > changes. Someone will commit a change and later we discover that the change > has been reverted.
Subversion does not lose your changes. As you said, they're still there in the repository history; you can get them back. > Everyone claims that they are updating before they work on files. Even if > this was not always true, the SVN clients should catch commits that were not > on the most recent files, correct? Almost certainly user error. A great way to get this to happen is: * You open a file in an editor and start working on it * Meanwhile someone else makes a change to the same file in their working copy and commits it * You try to commit but fails because the working copy is out of date because of the other change that was committed. * You update your working copy; Subversion merges the other changes into your working copy, *but your editor does not notice and does not reload the file* * You go back to the editor, make some other changes and save, thus re-saving your now old version of the file on top of the nicely merged file, thus "reverting" the other person's changes * You commit; it succeeds, "losing" the other person's changes You can avoid this by always looking at the output of "svn diff" before committing and ensuring that every change listed is one you actually intend to make. You should also use editors that reload files (either automatically or prompting you) that have been changed on disk by other programs.
