Re: Problem/bug with CVS

[H Brydon]

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

"Jim Hyslop" <address@hidden> wrote in message 
news:address@hidden
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12-07-06 2:28 AM, H Brydon wrote:
> > I have a new problem with cvs where it is not committing or
> > updating my files correctly.
> [...]
> > Two questions: (1) What is wrong with my sandbox and/or repository?
> > Hopefully this is a known problem with a simple solution.
> It's difficult to say without more information. Can you post the
> sequence of commands you used to reproduce the problem in your test
> directory?
>
> > (2) Are the day's file changes truly lost or are they hiding
> > somewhere?
> There should be a file in your working directory with same name as
> your original file, prefixed with .#, and with the original file's
> version number appended to it. For example, if the file name is
> afile.txt and it was revision 1.4, the saved file would be .#afile.txt.1.4
>
> However, if the .# file already exists, CVS will overwrite it. Since
> you've repeatedly updated and tried committing, the original file may
> now be lost.
>
> - -- 
> Jim Hyslop
> Dreampossible: Better software. Simply.     http://www.dreampossible.ca
>                 Consulting * Mentoring * Training in
>    C/C++ * OOD * SW Development & Practices * Version Management
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk/21kEACgkQLdDyDwyJw+PvjQCg/DZqnSxVoTxkMjTX6oC2syuQ
> iIMAoIZGFg7evtAIrZLNohhQ/cnWUyPp
> =hi6r
> -----END PGP SIGNATURE-----