Don’t you love upgrades that’ll break everything? For some reason now when I cvs init a repo the defaults have changed (where are they even stored?) and it’s been breaking things since going to Debian 9.
Although it presents itself as a warning if you see anything about warnings they apparently are errors. Such as this fine fatal error: “warning: duplicate LogHistory entry found.”. I was getting this from trying to login
cvs [login aborted]: unrecognized auth response from unix.superglobalmegacorp.com: cvs pserver: /ncc/CVSROOT/config [23]: warning: duplicate LogHistory entry found.
But it’s just a warning right? Well it turns out no, and that since I have multiple repos.
Apparently this was a bug in passing going back to 2006!
The problem is that a static variable is defined at line 618 in src/parseinfo.c. It is set when the first --allow-root option is processed for our first repository and then when the second --allow-root option is processed, the warning message is issued (erroneously, I believe) saying that another LogHistory line is encountered. But this is for a completely different repository, so it should have no relevance to the first config file.
Unless, serving multiple repositories is for some reason no longer
supported or the new syntax for using sections in a common config file is now mandatory. I hadn't seen any indications that either were intended, hence my question.
Thanks to Bob Bowen
The way out of this without re-compiling is to now comment out each repo’s LogHistory. Great.
The next issue at least presented itself as an error! .. if that’s progress.
$ cvs -d:pserver:[email protected]:/ncc ls .
cvs ls: failed to create lock directory for `/ncc' (/ncc/#cvs.lock): Permission denied
cvs ls: failed to obtain dir lock in repository `/ncc'
cvs [ls aborted]: read lock failed - giving up
Yep, now the lock directory needs to be specified. Maybe I should have made one per directory although this is pretty much just a read-only anoncvs so I don’t think it matters. And looking back on the logs it was only used by a few people so, honestly that’s fine.
The final error goes back to something I must have figured out with a template that is now wiped out. I have the CVS book, but left it at the office, so I’m here just hacking as a guess, but there is no passwd file being copied into place.
Logging in to :pserver:[email protected]:2401/ncc
CVS password:
Fatal error, aborting.
anonymous: no such user
This is at least simple to take care of, Just copy one from an older repo to a central location and propagate it everywhere. There is no point in doing system authentication as again it’s readonly and I don’t want users on my cvs crap thing.
So in 3 easy lines to remediate the thing, it is:
find ./ -type d -name CVSROOT -exec sed -i 's/LogHistory\=TMAR/#LogHistory\=TMAR/g' {}/config \;
find ./ -type d -name CVSROOT -exec sed -i 's/#LockDir\=\/var\/lock\/cvs/LockDir\=\/var\/lock\/cvs/g' {}/config \;
find ./ -type d -name CVSROOT -exec cp /virtual/unix/SOURCE/cvs-passwd {}/passwd
Current repos include such hits as:
- 32v
- binutils
- cblood
- cci
- coherent
- Corridor8
- CSRG
- darwin0
- darwinstep
- djgppv1
- dmsdos
- doom
- dynamips
- frontvm
- gas
- gcc130-x68000
- gcc1x
- gcc2x
- gdb
- gnumach
- gsmaster
- hatari
- linux
- linux001
- lites
- mach
- mach3
- machki386
- MacMiNT
- MiNT
- msdos-player
- ncc
- net2
- nextstep33examples
- ntsdk
- os2sdk
- pgp
- plan9next
- previous
- qemu
- quake1
- quake2
- research
- rsaref
- sbbs
- simh
- TekWar
- tme
- truecrypt
- uae
- Witchaven
- WitchavenII
- xinu
- xnu
General instructions are still valid on My crappy CVS archive of old crap is now online via pserver!
$ cvs --version
Concurrent Versions System (CVS) 1.12.13-MirDebian-25 (client/server)
$ cvs -d:pserver:[email protected]:/research login
Logging in to :pserver:[email protected]:2401/research
CVS password:
$ cvs -d:pserver:[email protected]:/research ls .
CVSROOT
researchv10dc
researchv10no
researchv3
researchv6
researchv6id
researchv6kw
researchv7hs
researchv7kb
researchv7ni
researchv7th
researchv8dc
researchv9
