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.
Arthur, Thanks for your reply. I found the roadmap location a bit unusual. I think that the wiki would be a better place for the roadmap (or it's copy) to reside. Of course it's content needs to be mirrored somehow to the march hare commercial pages. My point is: the community page should state the roadmap. Much like subversion's roadmap, for instance. It'd be easier to get more people involved and discussing the future of the product. One (good) collateral effect of that involvement and participation is more fidelity. Also, knowing what is being planned and what is going on, could avoid some of the current users to migrate to concurrent products, just because feature X or Y is promised for a future release of that product (or even it it's already implemented). It's good to know you already planned the distribution feature. It'd be nice to share and discuss the designs with the list members when the moment comes. Best regards Daniel Arthur Barrett wrote: > Daniel, > > The roadmap is in the FAQ: > http://march-hare.com/cvspro/faq/faq1.asp#9f > > Features planned for 2.6.01 > http://march-hare.com/cvspro/faq/faq1.asp#9i > > Distributed servers are in the plan (but not listed on the web). > > Our plan is similar to what you have proposed - but different too. We > are planning on introducing some distributed functionality in 2.6.01 and > some in 3.1.01 > > Are you volunteering to contribute? > http://march-hare.com/cvspro/faq/faq1.asp#1j > > The first step is to get the 2.6 core stable and tested, then adding the > distributed components planned for that release is relatively easy. > > Advocacy and marketing helps sales which keep the full time staff > employed of course ;) > http://march-hare.com/cvspro/faq/faq1.asp#9gc > > Regards, > > > Arthur Barrett > > > -----Original Message----- > From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf > Of Daniel Lapolla > Sent: 08 February 2006 03:07 > To: cvsnt at cvsnt.org > Subject: [cvsnt] Feature proposal - Distributed Servers > > > 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! > _______________________________________________ > cvsnt mailing list > cvsnt at cvsnt.org http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt cvsnt downloads at march-hare.com https://www.march-hare.com/cvspro/en.asp#downcvs @CVSNT on Twitter CVSNT on Facebook