> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
> Sent: zondag 5 oktober 2008 13:50
> To: alan.wood_at_clear.net.nz
> Cc: dev_at_subversion.tigris.org
> Subject: Re: [PATCH] Working copy on Samba share
>
> Ping, anyone has an opinion on this patch?
>
> Alan: using empty lines between paragraphs helps people read what you
> write (increasing the chance to get a response).
-1 on applying this patch without further review per case and a stricter set
of errors to retry on.
This patch just hides problems without resolving them.. and makes subversion
error later without good reason.
If a file is locked for a good reason that should stop the subversion
command, this patch will just delay subversion for several seconds.
Just retrying on every error condition is not a solution.
(Read http://blogs.msdn.com/oldnewthing/archive/2005/11/07/489807.aspx for
some of the reasoning)
Just last week we got a report from someone who found out a case in which we
retry file creation 100 times over 15 seconds to just create a file with a
unique name. In this case the filename happens to be the same as an existing
directory.
The retry loop in svn_io_file_open doesn't test for this error condition and
retries 100 times in +- 15 seconds.
The real solution in this case is of course to give a new name in the outer
loop instead of retrying the same not-unique name a hundred times.
This takes a few milliseconds instead of the 15 seconds waiting for someone
to delete the directory before checking the next name, that potentially has
the same issue.
Just retrying is not a solution. Adding more retries without looking for the
real cause is just asking for more problems. Another reply on the original
thread suggested that it is probably an issue in specific samba versions. (I
think it was somebody from the TortoiseSVN project)
I'm working on reviewing the existing retry loops as part of looking why
Windows fs access is called slow on this list.
If there are specific cases that need a specific retry that I should look
at, please let me know.
Bert
>
> Daniel
>
> alan.wood_at_clear.net.nz wrote on Mon, 22 Sep 2008 at 23:42 +1200:
> > Hi All,
> > I have been working on trying to make subversion working copies
> > behave on Samba shares.
> > This patch seems to solve two issues that I have seen.
> > The problems happen after a commit when the working copy is being
> > updated.
> > The first is that a rename would sometimes fail from .svn/tmp/blah
> > to .svn/blah2 or .svn/dir-props to .svn/dir-props-base
> > The second fault would be cannot access dir/.svn/lock. Both would
> > report 'permission denied'.
> > I have managed to trace this to places in the code where
> > GetFileAttributes and SetFileAttributes are called.
> > Both of these functions suffer from the same fate as described at
> > the top of io.c and which the macro WIN32_RETRY_LOOP() was written
> > to alleviate.
> > The FileAttribue calls are in the apr_ routines apr_stat() and
> > apr_file_attrs_set().
> > This patch wraps these two apr_ routines in the WIN32_RETRY_LOOP()
> > macro.
> > I have patched all uses of these two routines even though I have
> > only managed to trace issues occurring in
> > svn_io_set_file_read_write() called from svn_io_file_rename() and
> > io_check_path().
> > Tests so far confirm that the issues that I have been able to
> > reproduce have disappeared.
> >
> > Alan Wood
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-05 17:43:12 CEST