info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What is the best way to mount remote repositories?


From: Wayne_Johnson
Subject: Re: What is the best way to mount remote repositories?
Date: Tue, 2 Jan 2001 16:17:26 -0600



We've have a similar setup, only we have a true frame-relay WAN, rather than a
VPN.

I've heard that there are problems using CVS off of a NFS mounted filesystem.
Something about NFS not doing file locking right.

We use :pserver: protocol.  Our Camberley, England office had some pretty good
luck using the -z6 option to do data compression.  They claimed that they could
check out our source from Minnesota faster than they could check out their local
PVCS archive.  And they only have a 64Mb/sec pipeline out there, which is first
routed through El Segundo, CA.  Wish I could get frequent flyer points for these
packets.

One of the real benefits of using CVS's transports is that the file
reconstitution is done at the server side and only the reconstituted file is
sent across the network.  If you use NFS, you, in effect, force the entire
repository file to be transported across the network.  This may seem fast at
first, but as changes are applied to the repository file, it can get REALLY
bloated.  This is where PVCS really falls down.

As far as connection redundancy, neither pserver nor NFS can really help there.

What are you using for VPN?





"Jean-Claude Gervais" <address@hidden> on 01/02/2001 12:18:59 PM

To:   "CVS Info" <address@hidden>
cc:    (bcc: Wayne Johnson/MINN/Candle)
Subject:  What is the best way to mount remote repositories?



Hello,


     I work for a company that has offices in many different cities and
the Internet connects them all by VPN.

     There is source-code development work being done at all these sites,
and naturally, we'd like to access each other's source repositories.

     For example, let's consider that there are two sites, initially.

     We've tried installing one CVS server at SITE_A, and then remotely
logging in by CVS and TKCVS from SITE_B, but through the VPN connection, it
is very slow and unreliable. Worse, if ever the route to SITE_A is down (and
it does happen), then the developers at SITE_B are unable to perform any CVS
functions.

     The most important criteria for selecting a strategy to do this are
speed and reliability. How can we achieve this?

     The current strategy we're evaluating is this:

          First we put everything in Site A's CVS, including site B's
projects, with the following organization:

          /cvsroot/software/projects
              ????SITE_A_PROJECT1
              ????SITE_A_PROJECT2
              ????CVSROOT
              ????SITE_B_PROJECTS

          At SITE_A, we create NFS shares for SITE_A_PROJECT1,
SITE_A_PROJECT2 and CVSROOT.

          At SITE_B, we setup a CVS server.  We move the
SITE_B_PROJECTS folder from SITE_A to SITE_B's CVS root folder and share it
with NFS.

          Then we mount SITE_A_PROJECT1, SITE_A_PROJECT2 and CVSROOT
from SITE_A in SITE_B's CVS root folder.
          At SITE_A, we mount SITE_B_PROJECTS back where it was.

          So after this, both systems look like this:

          SITE_A:

          /cvsroot/software/projects
              ????SITE_A_PROJECT1  Local folder (fast!)
              ????SITE_A_PROJECT2 Local folder (fast!)
              ????CVSROOT         Local folder (fast!)
              ????SITE_B_PROJECTS  Mounted NFS share from SITE_B

          SITE_B:

          /usr/local/cvsroot
              ????SITE_A_PROJECT1  Mounted NFS share from SITE_A
              ????SITE_A_PROJECT2  Mounted NFS share from SITE_A
              ????CVSROOT         Mounted NFS share from SITE_A (a bit
slow *sniff*)
              ????SITE_B_PROJECTS  Local folder (fast!)


          CVSROOT must be the same for both systems to keep in synch,
so that is why SITE_B must mount it and thus pay a performance penalty.  But
I hope this will not be too dramatic.


          So, the question is: Is this the right way to do this?


     We're newbies at this, so please, be gentle!  :-)

     Thank You.


Attachment: winmail.dat
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]