You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Nicklas Norling <ni...@ifsab.se> on 2004/03/17 15:53:40 UTC
mod_deflate revisited
Hi all.
I'm having problems getting mod_deflate working when I found this:
http://subversion.tigris.org/issues/show_bug.cgi?id=1432
<http://subversion.tigris.org/issues/show_bug.cgi?id=1432>
The last comment is "waiting for httpd-2.0.48", well it's here now.
At least it's what David Summers have us Redhat guys install.
I really need compression so I'm asking you for a status update
on httpd and compression/mod_deflate.
Thanks for a great product!
/Nicke
Re: Loosing local changes during a commit
Posted by Folker Schamel <sc...@spinor.com>.
Ben Collins-Sussman wrote:
> ...
>
> 3. copy .svn/tmp/file to ./file, "retranslating" to native EOL style
> and re-expanding keywords with new values.
>
>
> If you don't have any eol- or keyword-translation active, then step 3
> never happens.
Ahhh, I see!
The file has EOL-style it set, yes!
>>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
>
>
> That is a true observation. As you suggested, perhaps setting the
> working-file to read-only during the commit might be enough...?
Would be fine for example.
It is no serious problem. You are right, I tried to be too clever,
effectively doing "something bad".
A trivial thing would be to add a warning to the svn book,
mention that you should not change the file while comitting.
Setting to read-only would be a nice thing!
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Loosing local changes during a commit
Posted by Ben Reser <be...@reser.org>.
On Wed, Mar 17, 2004 at 12:08:39PM -0600, Ben Collins-Sussman wrote:
> That is a true observation. As you suggested, perhaps setting the
> working-file to read-only during the commit might be enough...?
This is a bad idea. If we remove the write perms, it's difficult to put
them back correctly. If we always copy back out of tmp we might be able
to get the proper perms via the umask. But we aren't doing that...
--
Ben Reser <be...@reser.org>
http://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
Re: Loosing local changes during a commit
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-03-17 at 11:58, Folker Schamel wrote:
> 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?
Ah, yes, good point. I had forgotten about this. This is required
whenever EOL or keyword translation is active. The algorithm is this:
1. copy file to .svn/tmp/file, possibly "detranslating" in the process
(contracting keywords, and if svn:eol-style==native, converting to all
LF)
2. commit .svn/tmp/file to repository.
3. copy .svn/tmp/file to ./file, "retranslating" to native EOL style
and re-expanding keywords with new values.
If you don't have any eol- or keyword-translation active, then step 3
never happens.
> 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
That is a true observation. As you suggested, perhaps setting the
working-file to read-only during the commit might be enough...?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Loosing local changes during a commit
Posted by Folker Schamel <sc...@spinor.com>.
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
Re: Loosing local changes during a commit
Posted by Ben Collins-Sussman <su...@collab.net>.
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?
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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Loosing local changes during a commit
Posted by Folker Schamel <sc...@spinor.com>.
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.
This happend to me, because sometimes I have commits
needing 20 minutes or more (due to pre-commit scripts),
so I continue working while committing.
For a sample how to reproduce this (win32) see below.
Note that the output of "type myfile.txt" lacks
the lines 694 to 1077.
Probably this is not a bug in the strict sense
(re: "you shouldn't modify a file while committing!").
But somehow it is ugly...
Maybe there is a way to avoid this? For example,
setting the files to read-only during a commit?
Question:
Why is the working copy file modified at all?
Cheers,
Folker
***
C:\temp\svntest>svnadmin create repo
C:\temp\svntest>svn checkout file:///temp/svntest/repo wc
Checked out revision 0.
C:\temp\svntest>cd wc
C:\temp\svntest\wc>echo mytext >myfile.txt
C:\temp\svntest\wc>svn add myfile.txt
A myfile.txt
C:\temp\svntest\wc>start svn commit -m "" | for /L %i in (1,1,10000) do echo change %i >>myfile.txt
C:\temp\svntest\wc>echo change 1 1>>myfile.txt
C:\temp\svntest\wc>echo change 2 1>>myfile.txt
C:\temp\svntest\wc>echo change 3 1>>myfile.txt
<snip>
C:\temp\svntest\wc>echo change 9998 1>>myfile.txt
C:\temp\svntest\wc>echo change 9999 1>>myfile.txt
C:\temp\svntest\wc>echo change 10000 1>>myfile.txt
C:\temp\svntest\wc>type myfile.txt
mytext
change 1
change 2
change 3
<snip>
change 691
change 692
change 693
change 1077
change 1078
change 1079
<snip>
change 9998
change 9999
change 10000
C:\temp\svntest\wc>svn cat file:///temp/svntest/repo/myfile.txt
mytext
change 1
change 2
change 3
<snip>
change 691
change 692
change 693
C:\temp\svntest\wc>
***
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: mod_deflate revisited
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-03-17 at 09:53, Nicklas Norling wrote:
> Hi all.
>
> I'm having problems getting mod_deflate working when I found this:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=1432
>
> The last comment is "waiting for httpd-2.0.48", well it's here now.
> At least it's what David Summers have us Redhat guys install.
>
> I really need compression so I'm asking you for a status update
> on httpd and compression/mod_deflate.
What sort of status update do you need? httpd-2.0.48 no longer has the
mod_deflate problem. That means you can safely use mod_deflate with
subversion, and there won't be any more server-side buffering going on.
Your client will receive a streamy response.
To get this feature working, you need to activate mod_deflate on the
server side, and also make sure your run-time svn client 'servers' file
has 'http-compression = yes' in a relevant section.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org