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.
Long dissertation follows... The way CVS works in handling commits and tags etc is based on the concept of numeric file revisions. This is way down in the core of CVS and was inherited from RCS that precedes CVS. Each time a commit is made to the server there is a check: - Is the committed file the most recent revision? If this fails it means the user does not have the HEAD revision in his sandbox and cannot commit until he first updates (and merges) to HEAD. Then the CVS server assigns a new revision for the committed file by incrementing the least significant number in the revision and adds the data to the RCS file in the repository. Note that the way this is done is to put the HEAD revision in its totality in the RCS file and then storing reverse diffs for each revision based on the HEAD revision. This is done to speed up checkouts of HEAD. Example: Now imagine that you have two servers each with the same RCS file after your synchronization. Two developers check out this file each from his own server at revision 1.34. Both edit the file and it is time to commit. Developer A commits at UTC 13:51:58 and he will create revision 1.35, which contains his edits and everything before that. He also tags the file with some tag value. Developer B also commits but at UTC 13:52:11. He will have no problems and he will also create revision 1.35 which contains *his* edits and all previous ones as well. He tags the file with a different tag. Now, how could this be synchronized? File copying will completely erase one of the committed edits and the developer who committed to the "master" server will *win*, his revision will be the victor and his tag will live on. The poor sod who committed to the *slave* server will lose his edits completely even though he still has them in his sandbox. Not for long though.... When he updates his sources from the server there will be no merge because he has already revision 1.35 and his file is not changed locally. So he can move on and edit some more. When he next commits he will effectively add both öf his edits but these will be committed as revision 1.36 and the tag he has put on 1.35 is gone. But if he checks out again before doing his extra edits then his old edit is gone for good, because he will get rev 1.35 from the other developer.... Now, if he would update to the tag he would also lose the edits he did on revision 1.34 because these have been overwritten and cannot be restored. All in all, the synchronization cannot work with two live servers. There is no way CVS can handle the situation described above without loss of information. Possible solution? --------------------- The only way I can think of is a system with 3 servers where one is the real master, but is out of reach for all developers, only used for synchronization. The CVSNT audit to database would have to be used on the servers with user access and based on the data in the audit tables a special function will analyze what was done and when and then repeat this towards the master server while using the correct user logins and in the proper time sequence based on the audit time stamps. Since tags do not carry time stamps any other way of synchronization than using the database audit features of CVSNT will probably fail. After the master has been updated the two slaves will have to get their repositories modified with files from the master. Then of course the developer sandboxes need to be regenerated after a sync has been done because the local revisions will surely not be correct. But it would be possible to consolidate all operations this way using a real master. Note that the sync process needs access to both active servers and the master server so it might not be feasible on slow links. Possibly the process can involve some form of generation of update "packets" from each server being sent to the consolidator and then a sync packet being sent back containing the new RCS file for affected files..... Some software needs to be developed though, and the CVSNT server would have to be able to accept commits where the commit timestamp is forced from the client in order to set the correct times of the commits so that updates based on timestamps will still work. /Bo