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: Laine Stump
Subject: Re: What is the best way to mount remote repositories?
Date: 02 Jan 2001 15:48:46 -0500
User-agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7

>From the description of what you're proposing, It sounds like each
site has its "main" projects (which aren't worked on much by other
sites) and needs occasional access to projects mainly worked on by the
other sites.

Some recommendations:

1) NEVER NEVER NEVER NFS-mount a CVS repository!!!

2) Setup a CVS repository locally at each site that contains only the
   "main" projects for that site, make those repositories accessible
   via ssh, rsh, or pserver mode, and just use different CVSROOT
   settings to checkout the SITE_A and SITE_B projects. Once you've
   done the initial checkouts to your work directories, you won't need
   to specify the alternate CVSROOT for update, diff, commit, etc
   commands - CVS figures it out by itself.

P.S. Make sure you give each CVS repository its own local CVSROOT -
don't try to NFS-mount it either (as you've suggested in your original
message)

"Jean-Claude Gervais" <address@hidden> writes:

> 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.



reply via email to

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