[OpenAFS] Storing a CVS repository on AFS

[Russ Allbery]

Emil Ochotta <Emil.Ochotta@xilinx.com> writes:

> Background:

> I'm hoping to use AFS to improve read-times from a CVS repository.  We
> currently have the repository set up at one location and access it
> through a server via the CVS pserver (it's own TCP/IP client-server
> stuff).

My expectation is that you won't find you like this very well.  I've not
tried the particular configuration that you're talking about, and it's
possible that your current CVS pserver connections are really slow, but my
experience is about a 25-50% slowdown on CVS operations by putting the CVS
repository into AFS.  CVS does a lot of file creation and directory
operations, and isn't particularly light-weight on the file system.  (Its
backend storage method is not particularly efficient.)

I'm guessing that any speed gains you get from the AFS cache are going to
be swamped by that overhead.

If you can get away with read-only replicas (in other words, if commits
are infrequent and most operations are checkouts and updates), you may
want to look at CVSup to replicate your CVS repository and then just
having people switch to the master before doing commits.  There are some
scripts out there to help you with that, I believe.

Otherwise, I'd recommend looking at another revision control system that
supports distributed repositories better than CVS does.  Bitkeeper in
particular comes to mind, although the semantics of Bitkeeper are
significantly different than those of CVS.

> 2. Is there a concurrency race condition lurking in here?  CVS manages
> concurrency by creating a lock directory.  Is this operation synchronous
> on AFS such that a successful mkdir at any AFS client will guarantee no
> other AFS client could create the same directory.

Yes, AFS should handle this correctly.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>