[cvsnt] Feature proposal - Distributed Servers

[Daniel Lapolla]

Hello everyone.

I'm writing this proposal because I'd like to share and receive some 
feedback about this (still raw) basic idea. I'd like to improve the idea 
and uncover the flaws I'm overseeing.

I think it could be implemented in the CVSNT server with relative ease 
and maybe it can be present in some future CVSNT release (hope that not 
in a long term one).

Tony, I'd like to know what you think about this proposal. Is there 
anything like this proposal in the roadmap for the product? By the way: 
is there some sort of roadmap published for the product? It would be 
nice if the community could see what is being planned and for when it's 
being planned.

Regards

Daniel Lapolla



Porposal for Distributed CVSNT Servers
======================================

Motivation:
===========
Several users need to maintain replicated-read-only servers in order to 
support geographic distribution of development teams. The methods to 
maintain and update the replicas are conflict leading because they 
cannot cope with online updates. Also, I think it would be great for the 
product to have such feature.

I'm sure that there are several other motivations and complaints, so 
feel free to add them to the list.

Proposal:
========
CVSNT servers can be configured in two ways: master or slave.
A slave server must have a master server specified during it's setup. A 
master server is a master server.

CVSNT clients are connected only with their respective slave server. As 
far as I could go, they don't need to know that their host is a slave 
and that there is a master server.

Both the master server and it's slaves can accept write operations. The 
catch is that if a slave server receives a write operation, it will be 
forwarded to it's master. I know that it demands a connection with some 
minimal reliability and speed, but comparing this approach to the way 
most people do distributed CVSNT deployments, this is not a worst 
problem than the one we already have, right?

The master maintains a numbered list of successfully executed 
transactions so that slaves can, later, ask for the deltas of new 
transactions since his last update. At each transaction, the master can 
broadcast the availability of a new transaction delta to it's slaves.

If the slave is down for some reason, it can ask for the transactions he 
missed since his last sync, because the master keeps the list of 
transactions (as mentioned above).

For greater "updateness" of the slaves, they could also be configured to 
check for new updates with the master at each update operation performed 
by its users.

Changes to ACLs and other info commonly present in fileattr.xml or 
inside CVSROOT files would take place first in the master and then 
broadcasted to the slaves (or downloaded by them when they come up again).

In the future this schema could be improved to be more fault tolerant. 
For example a slave could be promoted to be a master if the master (or 
its connection) fails.

But for now, it would be a huge improvement over the methods that use 
rsync and other related tools.

That's all for now... Thanks for reading!