On Wed, Sep 24, 2008 at 15:55, <alan.wood_at_clear.net.nz> wrote:
> On 24 Sep 2008 at 18:06, Stefan Küng wrote:
>> Jason Wenger wrote:
> set up a working copy on a samba share. a single empty directory is
>>> Add a empty .txt file to the working copy and commit it. (this will work)
>>> Add a property to the txt file. Any property is sufficient.
>>> Attempt to commit the property.
>>> Commit succeeded, but other errors follow:
>>> Error bumping revisions post-commit (details follow):
>>> In directory 'J:\test'
>>> Error processing command 'committed' in 'J:\test'
>>> Can't move 'J:\test\.svn\props\foo.txt.svn-work' to
>>> 'J:\test\.svn\prop-base\foo.txt.svn-base': Access is denied.
>> Some users on the TSVN mailing list reported that this issue went away
> when they updated their SAMBA installation to the latest version.
> Do you have a version number ?
Linux is 2.6.11-1.1369_FC4smp
smbd is Version 3.0.14a-2
I have generally been annoyed by how non-repeatable the problem is. I would
> have a
> nice test that failed for a hour and then the next day would pass ever
Maybe not a lot of help, but running the setup above (Fedora Core 4 on
x86_64 host, smbd 3.0.14a-2), seems to be 100% reliable for testing from
what I've seen, when you try to commit a property edit.
> Setting the Samba share to "force create mode 0200" seems to help a bit,
> but does not
> solve it completely.
I will see if that changes anything in my setup.
> I also have a theory that TSVNCache is part of the issue, as I always have
> turned on for network drives. This is the only process that I have seen
> using the same
> network share as the one I am testing on. But this has been hard to repeat
> on my
> Stardom box ( seems to have broken "nt_notify" function), and I don't have
> access to the other Samba system from my home development environment.
I am running with icon cache disabled (tsvncache.exe not running) and can
confirm that the problems are still happening reliably, so far as I have
--Jason C. Wenger
Received on 2008-09-26 14:13:35 CEST