Quoting Greg Stein <gstein@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
Received on Sun May 4 11:08:55 2003