You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2003/05/01 01:24:45 UTC
Re: Error with commit/update on win32 in 5740
On Thu, May 01, 2003 at 12:11:26AM +0200, Arild Fines wrote:
> John Barstow wrote:
> > svn: start_handler: error processing command 'committed' in
> > 'C:/source/main/GCASv2/Assemblies/GCAS.StaticTables.Test' svn: Access
> > is denied. svn: svn_io_remove_file: failed to remove file
> > "C:/source/main/GCASv2/Assemblies/GCAS.StaticTables.Test/.svn/text
> > -base/Stat
> > icTable.cs.svn-base"
>
> I've been seeing similar errors as well. HEAD doesn't seem to be usable on
> Win32 right now.
Last week or so, Karl removed a chmod() call the svn_io_remove() function.
Previously, the function would *always* chmod the file to a writeable state
before trying to remove it. That had some performance problems for a few
reasons.
After the change, the assumption is that the caller would have to know when
to chmod the file *before* calling the remove function.
It sounds like you've hit a case where somebody is not properly chmod'ing
the file before calling remove...
Karl?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error with commit/update on win32 in 5740
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2003-05-04 at 05:08, brane@xbc.nu wrote:
> All code that calls svn_io_remove_file assumse that function will DTRT with the
> files in .svn. That's the way it should be, we shouldn't make everything outside
> svn_io have to know about .svn implementation details. I can't believe a chmod
> makes that much of a performance difference; if it does, then let's stop making
> the files in .svn read-only.
Agreed, though I'll note that the chmod is unnecessary on Unix systems,
so we could avoid the performance penalty there (perhaps with some help
from APR).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error with commit/update on win32 in 5740
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>Philip Martin <ph...@codematters.co.uk> writes:
>
>
>>Am I the only person who sometimes deliberately pulls a text base into
>>my editor in order to see the pristine version?
>>
>>
>
>No, you're not :-).
>
>
Weird; we need a switch for "svn diff" that uses the whole file as the
context.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error with commit/update on win32 in 5740
Posted by kf...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> Am I the only person who sometimes deliberately pulls a text base into
> my editor in order to see the pristine version?
No, you're not :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error with commit/update on win32 in 5740
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Äibej <br...@xbc.nu> writes:
> Philip Martin wrote:
>
> >On Windows perhaps, I think it's a useful feature on Unix.
> >
> If it's a useful feature on Unix, it's useful on Windows, too.
I should add it is less useful now that we have checksums, and the
text base files have a suffix, but I still think it is useful.
Am I the only person who sometimes deliberately pulls a text base into
my editor in order to see the pristine version? I suppose I might
stop doing that if 'svn cat -rBASE' could do it for me without
contacting the repository.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error with commit/update on win32 in 5740
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
>If it's a useful feature on Unix, it's useful on Windows, too. If that's
>the case, then we should look for the root of the "problem" (ignoring
>the fact that performance measurements show it isn't one):
>
>Windows filesystems don't allow deletion of a file if it's marked read-only.
>
>Well then, the solution seems straightforward: Add an option to
>apr_file_remove that will force the deletion even when the file is
>read-only. That's a no-op on Unix and a chmod on Windows (and probably
>OS/2 and Novell).
>
(Actually, it's a chattr, not a chmod.)
And the proposal for an svn_adm_remove_file still applies.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error with commit/update on win32 in 5740
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>brane@xbc.nu writes:
>
>
>
>>I can't believe a chmod makes that much of a performance difference;
>>
>>
>
>Disk IO is always important, particularly on shared network
>filesystems. However I did measure this a few months ago and the
>difference was lost in the noise.
>
That's what I suspected.
> Things may change if the overall
>performance of the wc library improves, but at the moment it is not
>important.
>
Exactly.
>>if it does, then let's stop making the files in .svn read-only.
>>
>>
>
>On Windows perhaps, I think it's a useful feature on Unix.
>
>
If it's a useful feature on Unix, it's useful on Windows, too. If that's
the case, then we should look for the root of the "problem" (ignoring
the fact that performance measurements show it isn't one):
Windows filesystems don't allow deletion of a file if it's marked read-only.
Well then, the solution seems straightforward: Add an option to
apr_file_remove that will force the deletion even when the file is
read-only. That's a no-op on Unix and a chmod on Windows (and probably
OS/2 and Novell).
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error with commit/update on win32 in 5740
Posted by Philip Martin <ph...@codematters.co.uk>.
brane@xbc.nu writes:
> I can't believe a chmod makes that much of a performance difference;
Disk IO is always important, particularly on shared network
filesystems. However I did measure this a few months ago and the
difference was lost in the noise. Things may change if the overall
performance of the wc library improves, but at the moment it is not
important.
> if it does, then let's stop making the files in .svn read-only.
On Windows perhaps, I think it's a useful feature on Unix.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error with commit/update on win32 in 5740
Posted by br...@xbc.nu.
Quoting Greg Stein <gs...@lyra.org>:
> On Thu, May 01, 2003 at 12:11:26AM +0200, Arild Fines wrote:
> > John Barstow wrote:
> > > svn: start_handler: error processing command 'committed' in
> > > 'C:/source/main/GCASv2/Assemblies/GCAS.StaticTables.Test' svn: Access
> > > is denied. svn: svn_io_remove_file: failed to remove file
> > > "C:/source/main/GCASv2/Assemblies/GCAS.StaticTables.Test/.svn/text
> > > -base/Stat
> > > icTable.cs.svn-base"
> >
> > I've been seeing similar errors as well. HEAD doesn't seem to be
> > usable on Win32 right now.
>
> Last week or so, Karl removed a chmod() call the svn_io_remove()
> function.
>
> Previously, the function would *always* chmod the file to a writeable state
> before trying to remove it. That had some performance problems for a few
> reasons.
>
> After the change, the assumption is that the caller would have to know when
> to chmod the file *before* calling the remove function.
Oh cripes. That chmod was there because the files in .svn are read-only, and you
can't remove a read-only file on Windows. Duh.
> It sounds like you've hit a case where somebody is not properly chmod'ing
> the file before calling remove...
All code that calls svn_io_remove_file assumse that function will DTRT with the
files in .svn. That's the way it should be, we shouldn't make everything outside
svn_io have to know about .svn implementation details. I can't believe a chmod
makes that much of a performance difference; if it does, then let's stop making
the files in .svn read-only.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error with commit/update on win32 in 5740
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> Last week or so, Karl removed a chmod() call the svn_io_remove() function.
>
> Previously, the function would *always* chmod the file to a writeable state
> before trying to remove it. That had some performance problems for a few
> reasons.
>
> After the change, the assumption is that the caller would have to know when
> to chmod the file *before* calling the remove function.
>
> It sounds like you've hit a case where somebody is not properly chmod'ing
> the file before calling remove...
>
> Karl?
That seems like a reasonable analysis, yeah.
John, can you file an issue with your reproduction recipe, and assign
it to me? Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org