> > As far as I know, repositories on NTFS work perfectly fine.
Talk via other channels suggests that placing a
Subversion repository / Berkeley DB database
on an NFS or NTFS partition works okay so
long as all the processes accessing the
repo/db are on the same machine.
That the reputed problems arise only
when processes on different machines
access the repo/db.
If this is true, then the warning from
the Subversion book may be toned down:
---+ Warning from the Subversion Book
Do not create your repository on a network share-it cannot exist on a remote filesystem such
as NFS, AFS, or Windows SMB. Berkeley DB requires that the underlying filesystem implement
strict POSIX locking semantics, and more importantly, the ability to map files directly
into process memory. Almost no network filesystems provide these features. If you attempt to
use Berkeley DB on a network share, the results are unpredictable-you may see mysterious
errors right away, or it may be months before you discover that your repository database is subtly
If you need multiple computers to access the repository, you should set up a server process
(such as Apache or svnserve), store the repository on a local filesystem which the server can
access, and make the repository available over a network. Chapter 6, Server Configuration covers
this process in detail.
True, I generalized from "remote filesystem",
"Windows SMB", "POSIX locking", to question whether
NTFS is okay.
As written above, local NTFS sounds okay.
Microsoft ships a POSIX compatibility kit,
so I suspect local NTFS is POSIX compliant
However, nearly all of my local NTFSes are shared
at some time or another, so I ask: if a local filesystem
is accessed remotely, does this cause a problem?
Me, I'm not so sure I want to take a chance.
I learned about not running CVS across NFS the hard way,
and at least in CVS it was fairly easy to repair
the damaged text files; I'm pretty worried about
maintaining the integrity of Berkeley DB files.
"Keeping lots of backups" is not reallly an answer,
if the corruption is latent a long time.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Apr 2 19:46:31 2004