[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN need to delete/create-temp/rename files instead of simply ove rwriting them (suggestion how to workaround)

From: Ben Reser <ben_at_reser.org>
Date: 2005-02-22 07:48:52 CET

On Sun, Dec 05, 2004 at 07:55:19PM +0100, Norbert Unterberg wrote:
> Please help me: What is so important to make the working copy file
> operation atomic? Couldn't the file could be locked during the
> operation? If a svn crash or interruption is your concern, the user
> needs to run svn cleanup afterwards anyway, which could take care of the
> incomplete operation when it finds the temp file.

I'm reading this thread with massive delay so please excuse me if you've
already figured this out. However, nobody seems to have given you the
answer to your question, Why is atomic file replations so important?

Many times we're taking your working copy file, that contains your local
changes and applying changes from the remote server. That file contains
the only copy in the world of these changes until you commit it. If we
replace the file in place, i.e. non-atomically, then the part of the
file would only exist in memory. If the computer were to lose power
before the write would finish then part of the data would be lost.

If you're talking about file system level locks, they can't resolve this
problem, they can only resolve race conditions. The only way locks
could solve this issue would be to completely change the model that
subversion uses to handle revision control from copy-modify-merge to
lock-modify-commit-unlock. The latter model doesn't have to worry about
merging server changes into files you have locally modified, because
while you're working on a file nobody else can modify it.

So any attempt to remove the atomic replacement functionality in the wc
code is risking your local modifications everytime you run svn up and is
downright foolish.

Ben Reser <ben@reser.org>
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 22 21:39:19 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.