Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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!