[OpenAFS] FSFS Subversion repository on OpenAFS 1.3.84 problems
Wed, 22 Jun 2005 12:51:25 -0400
Thank you for your reply,
I am aware that Subversion originally, with it's BerkleyDB backend, would not
work on AFS. I believe, however, that the FSFS (which is what we are using)
backend for Subversion was created so that the repository *could* be placed
on a networked filesystem such as SMB, NFS or AFS.
Some references below:
FSFS Subversion does appear to work perfectly when the repository is not
stored on AFS.
On Wednesday 22 June 2005 12:42 pm, Christof Hanke wrote:
> Blake Atkins wrote:
> > We are running a SuSE Linux Enterprise Server 9 AFS fileserver with
> > several Windows XP and Linux clients. Both the OpenAFS server and
> > clients are all version 1.3.84 and authentication is handled by
> > KerberosV. We have a Subversion repository that is being served via
> > OpenAFS and it is problematic. OpenAFS on the linux workstations usually
> > requires a restart to see some or all changes to the repository made by
> > other workstations. OpenAFS on the Windows XP clients occasionally
> > requires a restart due to an inability to access some files within the
> > repository; access fails with an error message: "The system cannot find
> > message text for message number.....".
> > Though I have not been able to locate it, I recall reading a post to this
> >list about a similar problem with CVS + AFS. I believe the solution was a
> >patch to the client source. I'm about to try downgrading the server and
> >clients to 1.2.13. Is anyone else using either 1.2.X or 1.3.X OpenAFS
> > with Subversion successfully?
> >Thanks very much,
> Hmmm, just a quote from the subversion-book:
> Other options can be listed with svnadmin help. As opposed to CVS,
> subversion is not based on RCS, but rather on the Berkeley Database.
> Make sure not to install a repository on remote file systems, like NFS,
> AFS, or Windows SMB. The database requires POSIX locking mechanisms,
> which these file systems do not support.
> Also, see the threads about byte-range locking earlier in this list.
> Boiled down, I wouldn't do that.