You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Gary Weinfurther <gw...@es3.net> on 2012/02/23 15:57:10 UTC
Lost changes
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. 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?
Server is VisualSVN 2.5.3.
PC Clients:
TortoiseSVN 1.7.5, Build 22551 - 64 Bit
Mc Clients:
SmartSVN 6.6.11
SmartSVN Early Access 7EA4
Subversion Client Adapter for Eclipse 1.6.12
Subversion JavaHL 1.6.17
SVN Team Provider Core 1.6.18
Versions 1.1.10 Build 1029
I am not subscribed. Please CC me on replies.
Gary
Re: Lost changes
Posted by Ryan Schmidt <su...@ryandesign.com>.
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.
Re: Lost changes
Posted by vishwajeet singh <de...@gmail.com>.
On Thu, Feb 23, 2012 at 8:27 PM, Gary Weinfurther <gw...@es3.net>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. 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?
>
I heard the similar argument in one of my training classes, but let me
assure you Subversion does not allow to commit on older version of files,
so the problem is with way your team is working, what must be happening is
that the person trying to commit later would be getting out of date error
and than he must be updating and getting conflict and he must be replacing
the file with his version and commiting it back, atleast this was the case
in the training which I was conducting, in such cases logs are your best
friend, go through the logs check the files on different revision if text
you can view the diff, if not you will have to manually review but you will
surely find the revision on which the previous commits changes were over
written by someone else.
Let us know how your review goes and findings.
****
>
> ** **
>
> Server is VisualSVN 2.5.3.****
>
> ** **
>
> PC Clients:****
>
> ** **
>
> TortoiseSVN 1.7.5, Build 22551 - 64 Bit****
>
> ** **
>
> Mc Clients:****
>
> ** **
>
> SmartSVN 6.6.11****
>
> ** **
>
> SmartSVN Early Access 7EA4****
>
> ** **
>
> Subversion Client Adapter for Eclipse 1.6.12****
>
> Subversion JavaHL 1.6.17****
>
> SVN Team Provider Core 1.6.18****
>
> ** **
>
> Versions 1.1.10 Build 1029****
>
> ** **
>
> ** **
>
> I am not subscribed. Please CC me on replies.****
>
> ** **
>
> Gary****
>
--
Vishwajeet Singh
+91-9657702154 | dextrous85@gmail.com | http://bootstraptoday.com
Twitter: http://twitter.com/vishwajeets | LinkedIn:
http://www.linkedin.com/in/singhvishwajeet
Re: Lost changes
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Thu, Feb 23, 2012 at 9:57 AM, Gary Weinfurther <gw...@es3.net>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. 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?
>
>
>
Your observation sounds right. Sounds like you really need to examine the
change history. For example, an automated procedure that is copying *back*
old files and committing them on top of old changes would cause just this
sort of problem. Also, if you have multiple Subversion servers in a
multi-hosted proxy or svnsync based setup, or you're using DNS to point to
a master and a slave server and the slave allows writes, you're ripe for
"split-brain" problems.
It does sound like a PEBKAC, though. (Problem Exists Between Keyboard And
Chair.) For example, if people are working in branches and not merging
changes carefully before committing to trunk, that could also cause issues.
And don't get me *going* on what clever people can do to git2svn gateways.
> Server is VisualSVN 2.5.3.
>
>
>
This is where I'd start looking. In particular, setting up a pre-commit
script to log or email a log of changes so that you have a transcript of
operations would be very helpful to debugging.
**
> PC Clients:****
>
> ** **
>
> TortoiseSVN 1.7.5, Build 22551 - 64 Bit****
>
> ** **
>
> Mc Clients:****
>
> ** **
>
> SmartSVN 6.6.11****
>
> ** **
>
> SmartSVN Early Access 7EA4****
>
> ** **
>
> Subversion Client Adapter for Eclipse 1.6.12****
>
> Subversion JavaHL 1.6.17****
>
> SVN Team Provider Core 1.6.18****
>
> ** **
>
> Versions 1.1.10 Build 1029****
>
> ** **
>
> ** **
>
> I am not subscribed. Please CC me on replies.****
>
> ** **
>
> Gary****
>
Re: Lost changes
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Feb 23, 2012 at 02:57:10PM +0000, 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. Everyone claims that they are
> updating before they work on files
Do people also always review the changes they are about to commit,
making sure what is being committed is really what they intend
to commit?
Editors with auto-save can cause this kind of problem.
E.g. the developer leaves the editor open with unsaved changes,
runs an update, svn changes the working file, and now the editor
saves the file on top of the new one overwriting the incoming changes.
If the developer commits the file other peoples' changes are undone
accidentally.
You can tell whether this kind of thing is happening by studying
the output of 'svn log --diff' and looking for unrelated changes
in existing commits.