[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Working copy on a network share

From: Colin JN Breame <colin_at_breame.net>
Date: 2005-09-23 13:14:48 CEST

On Friday 23 September 2005 11:35, Ryan Schmidt wrote:
> Wait, what? Are you saying that your BerkeleyDB-based repository is
> stored on a Samba share? If so, that would be a bad idea; a
> BerkeleyDB-based repository should only be stored on a local disk.

Agreed. I'm not doing this.

> I think you're instead saying that your repository is BerkeleyDB-
> based, and that it is on a local disk on the server, but that your
> working copy is on a Samba share, and that this is not working. If
> so, that should be unrelated to the storage engine used for the
> repository.

My working copy is BerkelyDB based and is stored on a samba share.

The problem is that, during update or commit, I get the error:

svn: Can't move '.svn/tmp/entries' to '.svn/entries': Permission denied.

Quite simply, the file '.svn/entries' does not have the write permission set
so the move from '.svn/tmp/entries' to '.svn/entries' fails. Maybe this is
related to my particular samba configuration. However, my feeling is that
svn is explicitly removing the write permission on .svn/entries when it is

The fix that I made was to always set the write bit before trying to remove or
overwrite(when moving) any file. This probably isn't the best way of doing
things as it no longer respects the write protected status of any file. The
most correct thing to do would be to explicity set the write permission
on .svn/entries (or any other known file) before trying to overwrite or

I was wondering if this was happening with the fsfs backend.

Has anyone else had this problem? (i'm using v1.1.4).

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 23 13:17:06 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.