[cvsnt] Distributed Teams and Multisite

[Rahul Bhargava]

WANdisco (http://www.wandisco.com)
has just released a multisite solution for
CVS repositories accessed using standard CVS protocol.
Works with any backend CVS server (including CVSNT)
as long as the client can communicate the std protocol.

Here is a short description of the approach:

If you look at existing solutions there is a preponderance
of two patterns:

1. Branching at each site - which is akin to partitioning
your "data-set" (in this case files in CM system), to avoid
collisions as updates arrive at local sites. ClearCase
Multisite is an example.

2. Centralized approaches whereby all transactions are send
to a single master.  CVSup is an example of this.

Both these approaches have been around for a while. They
address part of the problem but do not offer a seamless,
non-intrusive way for the CM admin to deal with the distributed
development paradigm.

In particular -

- Branching based solutions punts the difficult, often impossible,
problem of conflict resolution back into user-land - it is far from
transparent to the end user. Automatic merging can help to an extent,
but there will always be conflicts that the user has to manually resolve.

- Master/Slave solutions, the passive server and associated resources
(hardware & software) sit like a rock gathering dust waiting for
disaster/downtime to happen. They are primarily used for backup.
Resource utilization is poor. Existing solutions tend to be
unidirectional. Often, manual steps are required to have the primary
catch up with the secondary after a failure. Distance limitations exist
when synchronous replication is desired.

What is needed is a completely new way of looking at the problem and
addressing it in a
manner that ensures :

1. Write-Anywhere - Also known as Active-Active. Replicas should be able
to process updates concurrently without propagating updates to a master
or a primary node first.

2. WAN Scale - Offshore development is forcing Enterprises to access
their CM
servers over a WAN. The solution needs to scale on a wide area network.
It should deal with all the pitfalls of a long-haul network connection.

3. Performance - Typical CM clients should perceive significant
performance improvement. The overall responsiveness of a replicated
solution should be far better than a vanilla deployment of CM.

4. One-Copy Equivalence - The system of CM replicas should be
functionally identical to a single copy of a CM repository.

5. Reliability -
* The consistency of the CM Repository AND
* One-Copy Equivalence should not be compromised regardless of arbitrary
failures in the network, or arbitrary crashes of CM clients, or the CM
server itself.

6. Availability - CM server access should remain available in the
presence of all the above failures. In particular, there should be no
single point of failure. In the event of network segmentation, the
split-brain problem should not occur.

7. Transparency - The CM client should be unaware that it is using a
replicated CM server. In particular, no changes to the CM client should
be required to prepare it to use a replicated CM server.

If you look at our approach (http://www.wandisco.com/cvs) you can see we
avoid
all the pitfalls of centralization, master/slave or branching. This is
made possible
by the virtue of using our patent-pending distributed coordination
technology.

Right now we have applied our technology to CVS.

 From the CM user perspective they will see benefits like :

1. Local Reads

CVS commands like checkout, update, status, log are read commands. They
always pass through the Replicator to the local CVS server with no WAN
traffic.

CVS users typically do a lot of repository browsing, be it checkouts or
looking at change logs. Replicator always executes CVS read commands
locally ensuring low latencies for the end user. For an offshore site,
this is a huge win.

2. Rotating Quorum

Quorum is a minimal set of CVS nodes that must be available for a write
command. This amazing feature makes it possible to implement a
follow-the-sun development model. Offsite developers even when they
execute CVS write commands like check-in, tag, branching, do not see WAN
latencies! It's as if they have a local autonomous CVS server.
Patent-pending Rotating Quorum technology ensures that repositories
remain in sync.

3. Multisite, Active-Active Architecture

Replicator is the only game in town, that lets you setup
"write-anywhere" active CVS replicas without using half-way solutions
like branching and merge.

Load on any given CVS server is reduced, as read commands can be scaled
to multiple CVS servers. This provides better responsiveness to the end
CVS user.

There is no upper limit on how many active replicas you can setup. You
could setup one for each R&D site.

4. Reduced TCP Chatter,

CVS protocol is text based and verbose. A typical write command like
check-in incurs at least 4.5 network round trips. Our Replicators talk
via an optimized binary protocol.

We reduce the WAN traffic to 1 round trip. That's how long a CVS client
may have to wait to complete a write with our Replicator. Of course with
Rotating Quorum the CVS client's WAN latency can be reduced to 0!!


Regards,
Rahul Bhargava
CTO, WANdisco
http://www.wandisco.com