[cvsnt] Re: CVS - two way replication

[Rahul Bhargava]

Hi Peter :

Never say never again :-).

Using traditional  techniques this was not posible
to implement.  But  using distributed coordination technology,
WANdisco Replicator does do multisite replication.

With WANdisco solution:

- replicator proxy pA for server A  acts as the "coordinator" for  User
A's check-in on file X

- replicator proxy  pB for server B acts as the "ccordinator" for User
B's check-in for file X

-  CVS clients and servers are not aware of the proxies.

-  Using WANdisco's distributed coordination engine (DCone),  pA and pB
agree upon an  ordering. There are two possible orderings:
    +  User A gets ahead of User B  .
    +  User B gets ahead of User A

-  pA and pB both establish the same ordering using DCone.  Note there
is no central coordinator here.   No 2PC or merge gimmicks either. 
Replicator's local locking
scheduler creates a deterministic  partial order from the submitted commits.

- pA and pB submit  the same ordering of events (A:B or B:A) to server A
and server B respectively.

- Let us say the ordering was A:B.  Both server A and B will
indepedently reject User B's check in with  an upto date failed message. 
This is similar to how CVS server would
behave if two concurrent check-ins  showed up on same file X.

- WANdisco replicator maintains it's own locking scheduler (not a
Distributed Lock Manager) to determine the best partial order
from a concurrency perspective and yet achieve "one copy equivalance".

Also there is a notion of quorum to allow more than 2 nodes! You can
have replicator at every distributed team site and use flexibile quorum 
to acheive non-blocking ordering.

For further information take a look at WANdisco web page :
http://www.wandisco.com/cvs

Regards,
Rahul Bhargava

Peter Crowther
Thu Dec 2 14:47:15 GMT 2004 wrote:

> > From: Lahav Savir [mailto:LahavS at ixi dot com]
> > Does anyone has any idea how to create a two way replication of CVS
> > server,
>
> It's been discussed several times on this list.  In summary: You can't.
> The counterexample is as follows:
>
> - User A edits file X on server A.
>
> - User B edits file X on server B.
>
> - User A commits file X on server A.
>
> - Before any replication can happen, user B commits file X on server B.
>
> The problem: Both commits will be allocated the same revision number.
> This cannot be resolved later.
>
>         - Peter