Re: Repository access woes

Paul Smith wrote:

> I don't think this true: with a server implementation only one single
> host is accessing the repository regardless of how many different
> clients are running CVS operations. This is inherently safer than lots
> of different hosts accessing the repository directly.

As I understand it from discussions on the CVSNT list, the actual code used by
the server process to access the RCS is _exactly_ the same code as used by the
CVS client under local mode. The difference (as I understand it) from the NFS
side, is that some NFS implementations have the locking per client, so clientA's
locks won't necessarily block locks from ClientB. If there is only one client
process (i.e. the CVS server), then the locks will work fine (modulo bad NFS
implementations).

> You're right: "any" was far too strong; I apologize. However, I'm
> familiar with a lot of larger companies and as a rule they are moving
> away from local disk and towards NAS-style solutions. The latter is
> much simpler to back up, generally more reliable, and less expensive.
> It's not that unusual for companies to require that all critical data
> live on NAS.

Except for databases, that is, which is what we are talking about. Oracle is
similar to BerkeleyDB in that the database has to be on a local drive to the
server (though I think you can put the log files on a network share). I don't
even think under NTFS will Oracle run on a networked drive (for sure the
tablespace creation dialogue only lists local drives).

I will be testing mounting NAS volumes over iSCSI; it would be interesting if
Berkeley would work fine in that scenario, since the drives are "local" for most
purposes.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org