Hi Ben!
Ben Collins-Sussman wrote:
> On Wed, 2004-03-17 at 11:32, Folker Schamel wrote:
>
>>Hello!
>>
>>I suppose this is nothing new, but I couldn't find
>>any discussion about this topic yet:
>>When changing a file while committing,
>>you may loose these local changes
>
>
> When you run 'svn commit', the locally modified file is copied to
> .svn/tmp/, and then the tmpfile is sent to the repository.
>
> What you've done in your experiment below is to create a race
> condition. You have one process trying to copy the file, while the
> other process edits the file. Of course it's nondeterministic as to
> "how much" data gets copied. What do you expect?
I would expect the following:
During saving from my editor, either my editor or subversion bings
the famous error message "cannot access file, because it is
used by another application", if both access the file at the same time.
If there is no such error, I expect that no changes get lost.
> There's nothing that can be done here. Even if we weren't copying the
> working file to .svn/tmp/, and simply sending the working file directly
> to the server, you'd have the exact same race condition.
Race condition is fine; the problem is loosing data.
The problem seems not to be copying INTO .svn/tmp/.
This would be fine, because either you get the error mentioned above,
or if the file already has been copied, and svn would only work
on this copy, you could modify your original without loosing your data.
However, it seems that svn copies the file BACK from .svn/tmp/ into .
Is this necessary, also if the file does not contain strings
which must be replaced?
And if there is a need for such a copy,
subversion could keep the original file open, to avoid other applications
accessing the file.
Or maybe subversion directly works on the file,
causing all other applications being not allowed to access the file.
> If you run 'svn commit', you're telling the client to send your file to
> the server. If you change the file while it's trying to do that, then
> you're doing something very bad. 'svn commit' is not meant to be, nor
> can it be, parallizable. There's nothing to fix here.
Of course I am aware that there may be racing-conditions.
However, since I know that subversion copies the files into the .svn/tmp/,
I assumed that after svn says "transmitting files",
the file is already copied into .svn/tmp/, and now it is safe
to continue work on the original file. Which seems to be wrong. ;-)
Subversion seems to be protected by complicated locking mechanisms
against another svn instance accessing the wc data in parallel;
but it seems to be not protected against any other app accessing the
wc data in parallel.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 17 18:59:08 2004