Re: Problem/bug with CVS

"H Brydon" <[email protected]> Mon, 23 Jul 2012 16:04:23 -0500
Newsgroups gmane.comp.version-control.cvs.general
Organization Reasonable
Message-ID <[email protected]>
I just upgraded the disk my cvs repo is on and discovered something new.  I 
previously reported (below) trouble committing existing 'file.cpp', 'file.h' 
and creation of new files.

Summary: The new files were not showing up in the repo following a 'cvs 
add'/'cvs commit' sequence that indicated success.  The 'file.cpp' and 
'file.h' had trouble where the .cpp file was showing false conflict info and 
the .cpp and the .h file would not commit without "-f" flag.

I just discovered that the new files and one version of the .h file showed 
up in the top level of the repo (ie. not in the directory where they 
belonged).  A couple of other files were also there which I had not 
previously detected problems with.  The .cpp file was not there however and 
that part of the problem is still a mystery.

--
Harvey

"H Brydon" <[email protected]> wrote in message 
news:[email protected]...
> More details: I figured out that if I force the wayward files to commit 
> with "-f", then other weird things happen.  I found that
>
>  cvs commit -m "Blah" -f file.cpp
>
> will get it to commit.  The $Log$ info in the file is updated with a new 
> version of the file (eg. 1.13) however if I then do a 'cvs update', it 
> clobbers the file with the 1.6 version (and deletes the $Log$ history back 
> to 1.6).  Everything from 1.6 to 1.13 is gone.
>
> I also added some files with 'cvs add' and committed.  Messages indicated 
> that they were accepted (info gone now), however creation of a new sandbox 
> did not create the files.  I telnetted to the server and can see that the 
> files are not in the repo.
>
> I rebooted the cvs server (Ubuntu 11.04) and saw that the file mentioned 
> above in the repo is 1.6 (still) and the new files are not there.
>
> Since the reboot (I'm not sure that the reboot changed any behavior), I am 
> still getting the 'conflict' stuff on file.cpp but I found that if I do 
> either
>
>  cvs commit -m "Blah" -f file.cpp
>  cvs commit -m "Blah" file.cpp
>
> the the wayward file now will commit to the repo but if I just do
>
>  cvs commit -m "Blah"
>
> then cvs complains thusly
>
> cvs commit: file `file.cpp' had a conflict and has not been modified
>
> and the commit does not happen.
>
>
> For the new files, ... they were stuck in some sort of limbo in that they 
> were not in the repo but I could not add them without mentioning them by 
> name:
>
> cvs add Hard*.txt
> cvs add: scheduling file `Hard001.txt' for addition
> cvs add: scheduling file `Hard00245.txt' for addition
> [snip...]
> cvs add: use `cvs commit' to add these files permanently
>
> cvs commit -m "Blah"
> cvs commit: Examining .
> [snip...]
> cvs commit: file `Hard001.txt' had a conflict and has not been modified
> cvs commit: file `Hard00245.txt' had a conflict and has not been modified
> [snip...]
> cvs [commit aborted]: correct above errors first!
>
> cvs commit -m "Blah" Hard001.txt
> /media/ddrive/cvs/.../Hard001.txt,v  <--  Hard001.txt
> initial revision: 1.1
>
> Mentioning the files explicitly made the commit acceptable and got them 
> added to the repo (I have verified that they are actually there).
>
> The big picture is that I have a crisis of confidence in that cvs tells me 
> that files are added to the repo when in fact they are not.  Sometimes I 
> get messages indicating failure, but sometimes not.
>
> -- 
> Harvey