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.
Bernhard Merkle wrote: > what it the recommended way to mirror or synchronize cvs repositories ? > > I would describe mirroring as: > server A does READ/WRITE access, while server B only has READ access. As I understand it, you have two possibilities: either replicating every commit action that goes to A also on B, or synchronizing the repository files from A to B. The latter could be done on request (after every commit) or in timed intervals. Additionally, the clients that access B for reading need to be aware that they need to access A for writing (committing, tagging, etc). This could probably be handled by routing calls to cvs through a pre-processor (script or program). I once saw a site that advertised a tool for this (mirroring cvs repositories), but I didn't keep the link and can't find it anymore. > - This sould be possible with CVSNTUp or simply copy the whole > repository ? (while CVSNTUp seems to be more efficient ;-) I don't think cvsntupd works well with mirroring repositories. In fact, I can't see how it would work at all; it seems to automatically update a /sandbox/ (not a second repository) whenever there are commits to the repository. How do you imagine (ab)using it for this? Possibly one of the many file synchronizing tools could work, running on the repository itself. Special care is probably needed for handling concurrent file access attempts by the cvsnt server and the synchronizing tool. > I would describe synchronize as: > BOTH server A and B are doing READ/WRITE . > > - Is this possible with cvs ? > (I can imagine all kinds of problems with time synchronization, > conflicting changes etc.). I think cvs is NOT designed for distribued > repositories with READ/WRITE access, right ? It probably could be done putting something in front of cvs that synchronizes every commit between the multiple servers. Commits would be slower, of course, as the servers either need to talk to each other, or the client needs to talk to every server. Gerhard