You haven't gotten any response because this isn't a CVS question and you haven't provided enough details for anyone to even begin to point you in the right direction. What platform(s) are you on? Is
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)
Simon Renshaw wrote, On 10/31/2007 10:16 AM: Hi, I have a question concerning locks. From time to time a dev try to commit a file and it just hang there. When this happen, I look in the repo and I fi
This can happen when the timestamp on the file is different than the timestamp in the CVS/Entries file which in turn can happen if your tree is using NFS storage on a machine that has a different con
Heh, or just as likely that someone has been getting a bit overenthusiastic and trying out all the exciting possible options in the config file without realising that they've been reading a version o
But that immediately raises the question of where you got a config file that doesn't match your server. It sounds like you have multiple versions of CVS installed on the server or your repository is
Thanks everybody, to my surprise, I solved everything with the simplest solution: Restart the CVS services in Windows. Although I do not understand why, but after I stop the CVS services, backup the
--Original Message-- I beg to differ. What Christopher really, _really_ needs to do is "make an emergency backup of the entire disk RIGHT THIS VERY SECOND". .... and *then* start figuring out what we
It may be quite possible, but it's extremely unlikely. I can't think of any possible failure mode that would just result in duplicate lines. All the likely failure scenarios involve missing data. Or
Apparently not, or you wouldn't be getting "Permission denied". :-) Have the user try to rename the file from the command line -- you'll undoubtedly get exactly the same result. If your repository is
If all you are wanting to protect is the contents of the $CVSROOT/CVSROOT directory, then I agree, Mark's suggestion is overkill. usually, what I believe, you want can be done with directory permissi
First, figure out how the corruption happend and make sure it doesn't happen again. The most common cause is accessing the repository with NFS (or some other network file system), although hardware p
The platform is windowsNT. It's a client server mode and I'm using cvsnt_1.11.1.3. I have some jar files that need to be updated so on the server side I've added the .jar extension to the .cvswrapper
Please don't send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! No. Most likely, your "local" directory isn't really local and there are bugs in your network file system (
Unfortunately, that indicates that your repository has been corrupted. Are you using any kind of network file system (NFS, Samba, Windows File Sharing, etc.) to access your repository? If so, that's
Using a network file system like SAMBA to access your repository is not recommended -- you'll likely encounter any number of strange permission problems and may end up with a corrupted repository. Us
Is your working directory on some kind of network file system? -Larry Jones These pictures will remind us of more than we want to remember. -- Calvin's Mom
That implies that the repository file has been corrupted. The current development version of CVS will give you a bit more information about exactly what is corrupted. If you're using some kind of net
That looks like you've got the remote repository mounted on a local directory using NFS or Samba or some other network file system. If so, DON'T DO THAT, it's a recipe for disaster. Just access it us