Hi Peter,
Peter Toft wrote: > In the release of CVS 1.12.13 (Oct. 3 2005) it was noted that > "[http://www.kb.cert.org/vuls/id/680620 #680620] for more info), > several issues involving potential data-loss on heavily loaded > systems, some minor potential crashes, hangs, and several minor > annoyances in CVS client and server behavior." > > Can anyone tell more on this? I have recently found severe problems I believe I was referring to these NEWS items (from the NEWS file) in that release announcement. The notes in parentheses are new annotations: * Thanks to Rahul Bhargava <[EMAIL PROTECTED]>, heavily loaded systems suffering from a disk crash or power failure will not lose data they claimed to have committed. (CVS used to print its commit success messages prior to syncing to disk.) * CVS now does correct locking during import. (`cvs import' wasn't creating any locks! Imports were apparently rare enough that it took a long time for anyone to notice and report this.) This fix may also be seen as avoiding data loss on heavily loaded server, but it is less critical since it only affected the history and val-tags files: * CVS now locks the history and val-tags files before writing to them. Especially with large repositories, users should no longer see new warnings about corrupt history records when using the `cvs history' command. Existing corrupt history records will still need to be removed manually. val-tags corruption should have had less obvious effects, but removing the CVSROOT/val-tags file and allowing a 1.11.21 or later version of CVS to regenerate it may eliminate a few odd behaviors and possibly cause a slight speed up of read transactions in large repositories over time. There is also this enhancement, which fixes a long standing CVS deficiency, but only lost data if the user didn't notice the conflict message and subsequently deleted the .#* file created by CVS in their sandbox: * CVS now remembers that binary file merge conflicts occurred until the timestamp of the updated binary file changes. There is also this fix, which only applies to the (hopefully rare) case of Windows clients accessing a *local* repository *concurrently with older clients*, but which could cause data loss: * The Windows client now creates locks compatible with older versions of CVS by default. This should only be relevant if your client is accessing a local repository concurrently with another, older client. If you would like to disable compatibility mode (because it is slightly faster), edit the LOCK_COMPATIBILITY flag in windows-NT/config.h and recompile. For more information on any of these issues, you may refer to the ChangeLogs, the [email protected] email archives, and the CVS repository itself. > with CVS 1.12.9 - which very well can originate from clients having a > very high CPU load committing huge files through an SSH pipe towards > the CVSROOT on a remote machine where the network is not the fastest > one. I have seen checksum errors and locking problems with CVS 1.12.9 > from time to time. I am not aware of any current problems in the 1.12.9 code which might cause checksum errors. CVS watches its network pipes and should be waiting to write data when their buffers are full. If it is not, then please report it as a bug. Your locking issues may have been a symptom of the import problem. I know of no other problems. This problem existed in both 1.11.x and 1.12.x. You may like to know that there is a problem with 1.12.13 clients communicating with older servers. We've fixed it in 1.11.22 and the 1.12.x trunk, but it is waiting for the 1.12.14 release, which will hopefully be in the next week or two. Cheers, Derek -- Derek R. Price CVS Solutions Architect Get CVS support at Ximbiot <http://ximbiot.com>! v: +1 248.835.1260 f: +1 248.835.1263 <mailto:[EMAIL PROTECTED]> _______________________________________________ info-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/info-cvs
