Central CVS server Vs Local CVS server

Question

I am working in a project in which we are using CVS for version control. But problem is Central CVS server is in Chennai(India) and We have to access or checkout the code from Gurgaon(India) on daily basis. It takes around 7 hours in checkout. It is time consuming.

What we want is We need to configure a Local CVS Server and import the code by checkout from Central CVS serverm so that we can checkout from local server easily. But there are two problems in this step -

1. Is it possible to Create Local CVS server by checking out the code from Central CVS Server and using the code to import in local CVS server ?

2. If first step is possible , how can we sync the Local CVS Server with Central CVS Serval

Kindly help me. or Is there any alternative to achive my purpose ?

Answer 1

CVS is not a distributed version control system, so most implementations do not support the concept of deploying more than one server for the same repository (i.e. local and remote).

That said, the CVSNT page at Wikipedia notes:

In November 2008 the project released version 2.5.04 with support for
multi site repository replication or 'local' repository caches and
specific performance features for using large files use over a WAN.

CVSNT is a commercial product now, so this can present a challenge to those that prefer free solutions. (As any good closed tool vendor would say, CVSNT appreciates the saying that free is not free, but this is an entirely different matter.)

Transitioning a CVS repository to CVSNT should be trivial with minimal complication since CVSNT derives from CVS. Migrating a complex CVS repository to a DVCS is not necessarily trivial or without risk, particularly if the CVS repository has sustained meddling with revisions, tags, branches, and what not.

As any effort of this nature is likely to require significant changes throughout the organization, so if one is going to embark on such an effort, it seems prudent to consider the possibility of migrating to a more ubiquitous DVCS.

CVSNT is not the only commercial vendor of CVS repository replication solutions. For example, the WANdisco page at Wikipedia says:

WANdisco provides replicated products for CVS, Apache Subversion, Git, Gerrit and Apache Hadoop.

Note that mention of commercial products is decidedly not an endorsement of them, nor is it a recommendation. The information shared simply affords the reader some knowledge of potential options in such a situation.

Other potential solution paths exist. Web searches on the topic of "cvs repository replication" produce results indicating that some CVS users have tools like a Distributed Replicated Block Device to distribute access to the file store where the repository resides.

Furthermore, for better, or worse, depending on the level of concurrency between local and remote development, it is sometimes plausible to leverage a DVCS to reduce interaction with the remote server without changing the remote server, but do recognize that the paragraph that follows is presented only to share a potentially non-obvious solution to someone that does not want to migrate the remote repository to another VCS for one reason or another.

This respondent has seen instances where a CVS checkout is committed into a DVCS so that other developers can then leverage the DVCS to work with the checkout in a distributed manner. As needed, the underlying CVS checkout is periodically merged with the CVS server. Of course, this adds significant complexity, is not satisfactory in a situation where local developers need access to the entire remote repository, and is unwieldy when both local and remote developer concurrent use of the branch is high. The idea is really only suited for situations where remote and local development is loosely coupled (i.e. the remote developers where the repository resides are not heavily involved with the code shared via the DVCS).

See also: * How to run CVS in parallel with a (“centralized”) DVCS repository?