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

Re: Issue #1509, shared working copies and svn:executable

From: Ben Reser <ben_at_reser.org>
Date: 2004-07-01 01:08:42 CEST

On Wed, Jun 30, 2004 at 12:21:30PM -0500, kfogel@collab.net wrote:
> If you rename a file F to new name N, while a user is editing F, and
> then the user saves, what happens? They write their changes out to F
> again. But that sounds a bit different from what you describe above.
> In general, if the window of risk is small, I think shared working
> copy support is worth it. But we should understand exactly what can
> happen. I don't yet feel I understand precisely what the data loss
> scenario looks like here. Could you give a concrete example? Maybe
> we can find a way for Subversion to at least detect that something
> funny has happened, and warn the user who ran the update...

I'd guess this is a very OS, filesystem, and editor specific

But here's an example with vim and Linux on ReiserFS:
$ echo foo > foo
$ vi foo
(At this point I append +localmods in my editor buffer but don't save)

From a different shell I do:
$ mv foo foo.tmp
$ cp foo.tmp foo

If I try and write to the file at this point vim says:
WARNING: The file has been changed since reading it!!!
Do you really want to write to it (y/n)?

I say yes and:
$ grep -H . foo*

vim in this case will write to the proper file. I tried it again,
$ rm -f foo.tmp

before writing to the file and, vim still behaved properly. It is
possible that some editors will behave differently. If the editor opens
the file and holds it open, then writing back to the same filehandle.
Things would look very differently. Changes would be written to
foo.tmp. Here's an exmaple perl script and a walk through of what


use Fcntl;

open FOO, "+<$ARGV[0]" or die $!;
my $line = <FOO> or die $!;
chomp $line or die $!;
my $wait_for_input = <STDIN> or die $!;
seek FOO, 0, SEEK_SET or die $!;
print FOO "$line+localmods\n" or die $!;
close FOO or die $!;

$ rm -f foo*
$ echo foo > foo
$ perl editor.perl foo &
$ mv foo foo.tmp
$ cp foo.tmp foo
$ fg
(hit enter)
$ grep -H . foo*

Now let's try again while deleting the temp file before writing:

$ rm -f foo*
$ echo foo > foo
$ perl editor.perl foo &
$ mv foo foo.tmp
$ cp foo.tmp foo
$ rm -f foo.tmp
$ fg
(hit enter)
$ grep -H . foo*

And the users changes silently disappear. I'd imagine this is the most
common behavior. Some filesystems/OSes might have an error that the
editor could pick up.

Frankly, I'd say that any editor that behaves like that perl script is
broken. A proper editor should behave the way vim does, warning you
that the file changed, and writing to the name (not the filesystem
node). I'm gonna bet that some people will disagree with me on this and
maybe even some editor implementations.

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 Thu Jul 1 01:10:22 2004

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.