info-cvs
[Top][All Lists]
Advanced

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

Re: Multisite CVS, Continous Availability and other goodies ...


From: Rahul
Subject: Re: Multisite CVS, Continous Availability and other goodies ...
Date: 18 Jan 2005 17:07:21 -0800
User-agent: G2/0.2

SSH Support
===========

Yes SSH is fully supported.  We bundle a "cvsrelay" executable
that  gets invoked by SSHd. It directly
relays CVS commands to our CVS Replicator. This
is further detailed in the admin guide, see
http://www.wandisco.com/cvs-admin-guide.htm .

A nice consequence of using the cvsrelay  is SSHd could be
hosted on a separate box independent of CVS server.
This could be useful for example if the SSHd box is closer to the
firewall and the CVS server box itself is on an internal network.
But this is optional, you can have the std deployment -
SSHd and CVS server on the same box.


Update Speed
============

As you stated : presuming the network and servers are operating as
normal, the updates will be available to your remote colleagues pretty
much instantaneously. Probably before the email or IM ping from you
reaches them asking them to do a "cvs up" :-) . In any case if they do
a concurrent commit with respect to your commit, one of the commits
will be rejected. No change from the normal CVS semantics. The
distributed
coordination engine (DCone) underneath is responsible for making the
"distribution" transparent to the end user.

To take a practical example, say that you had a remote team in
Bangalore, India and  a team in San Jose,CA. Presuming normal WAN Round
Trip time  (RTT) of ~ 250 ms between the two cities and a T1 line
(1.5Mbps) , for a typical CVS check-in (< 10KBytes) you should have the
remote CVS repository be updated in < 1 s after your check-in has
completed.
Of course consistency is always maintained. If the remote developer
were to
do a concurrent conflicting check-in while your update was being
applied,
the Replicator will ensure proper ordering and conflicting check-in
will
be rejected with std cvs semantics.

If you use a direct CVS connection from Bangalore to San Jose i.e.
without going through our replicator, a typical CVS ci will cause 4.5
RTT. We maintain a persistent  binary connection between the two
replicators, the WAN latency encountered is only 1.5 RTT with our
replicator in place. The reduction in latency comes about because
we keep a persistent connection between the replicators and do not
have CVS protocol chatter on the WAN.

So even for remote case, you should see faster CVS updates!

Let me know if I can provide more clarifications.
Regards,
Rahul Bhargava
CTO, WANdisco



reply via email to

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