I have backups but the thought of having to rebuild the archive from last January is daunting as I'm not sure how far back the corruption occured. I did make a copy of the cuorrupted archive in a tes
The file is corrupt. As always in these kinds of cases, I strongly suggest that you immediately run the repository verifier (either contrib/check_cvs or validate_repo depending on the version of CVS)
Matthew Rich wrote, On 11/15/2007 12:31 PM: I'm getting this error when tring to get a log on this file: cvs server: warning: duplicate key `log' in version `1.11.2.9' of RCS file `/Root/Products/Sel
The "advantages" are that you get to learn a lot about the internal format of RCS files and how well your backup/restore process works as you try to fix the repository file corruption that will proba
Hi, Eric: If the only problem were that, then wouldn't be no problem at all. Regarding the line-end problem it is stayed somewhere on big bold letters *don't share repos among platforms*. I for one,
On Tue, 17 Sep 2002 11:57:30 -0700, Matthew Navarre <address@hidden> asked: The format of the rcs ,v file does not include any kind of a checksum, so any corruptions that occur across a network files
Yah, I know. I've been trying to change it to using ssh, but keep getting "but... it works now" from TPTB. That's why I'm basically collecting ammo. They want us to use wincvs with a SMB mounted repo
This seems to cause an undue amount of repository file corruption, and should be avoided. What do you mean with the repository on a mapped drive? If it's at a remote site, use some sort of client-se
That is an extremely foolish thing to do. Essentially every report of repository corruption we've ever received has been caused by a network mounted repository. You should either put the repository o
The problem is different from the one with a remote-mounted repo, where one risks repo corruption due to O/S bugs or similar problems. In the case of remote mounted sandboxes, the problem is with lin