[lmi] Using git to manage CVS webpages repository

[Greg Chicares]

On gnu savannah, webpages are maintained only in a CVS repository, at
least for now. That might change:

https://lists.gnu.org/archive/html/savannah-hackers-public/2017-09/msg00021.html

but until it does, CVS must be used to update the lmi webpages. It's
been years since I worked with CVS, and last year I didn't even make
time to update the copyright notices (nothing else needed updating).
This year, I decided to figure out how to manage the CVS repository
with git tools. Although it's good to explore the capabilities and
limitations of that method, for simple tasks like copyright updates
it's easier just to use CVS. It turns out that the git tools update
the CVS repository only by invoking CVS commands, and require a CVS
checkout to exist anyway.

(0) Update ECDSA host key

This key has apparently changed since I used it last. Accepting the
new key, after verifying its fingerprint, allowed me to continue,
although this warning appeared each time:

Warning: the ECDSA host key for 'cvs.sv.gnu.org' differs from the key for the 
IP address '208.118.235.201'
Offending key for IP in /home/greg/.ssh/known_hosts:6
Matching host key in /home/greg/.ssh/known_hosts:7

...so I obliterated all keys for that host...

ssh-keygen -f "/home/greg/.ssh/known_hosts" -R 208.118.235.201

...and re-accepted the new (fingerprint-verified) key.

(1) Managing the cvs repository using git tools

In the past, I had maintained a local checkout of the webpages
repository, but I stopped doing that when I migrated to a new machine
because I used it so rarely. Therefore, I conducted this experiment in
a temporary directory:

[as superuser] apt-get install git-cvs
touch ~/.cvspass

cd /tmp
mkdir web
cd web
git cvsimport -v -d "[USER][AT-SIGN]cvs.sv.gnu.org:/web/lmi" lmi

[That was the step I found most difficult, but only because I have two
different savannah usernames and I first used the one to which my
~/.ssh credentials do not pertain. Assuming that I had used the right
username, I tried everything else I could think of, to no avail, until
eventually I found that this:
  git cvsimport -v -d 
":pserver:anonymous[AT-SIGN]cvs.savannah.nongnu.org:/web/lmi" lmi
succeeded, leading to a blinding glimpse of the obvious.]

...change some files...
git commit --all

That worked as expected, creating a 'f1759c9' SHA1.

GIT_DIR=./.git git cvsexportcommit -vupc -d 
"[USER][AT-SIGN]cvs.sv.gnu.org:/web/lmi" f1759c9

That command failed:

/tmp/web[1]$GIT_DIR=./.git git cvsexportcommit -vupc -d 
"[USER][AT-SIGN]cvs.sv.gnu.org:/web/lmi" f1759c9
Applying to CVS commit f1759c9c74d6c2a16af2393bb8f502717a596857 from parent 
b531547d4890aaa581c7f287e9644268922234ca
Checking if patch will apply
Enter passphrase for key '/home/greg/.ssh/id_rsa':
cvs update: cannot open CVS/Entries for reading: No such file or directory
cvs [update aborted]: no repository
cvs -d [USER][AT-SIGN]cvs.sv.gnu.org:/web/lmi update 7702.html COPYING.html 
ChangeLog README faq.html group_tutorial.html index.html 
individual_tutorial.html menu_commands.html pasting_to_a_census.html 
sequence_input.html user_manual.html:  256 at 
/usr/lib/git-core/git-cvsexportcommit line 436.

Apparently this technique requires two distinct repositories: the git
repository in this directory, and a separate CVS checkout in another.
I created the latter (below) and reissued that command in the CVS
directory, and it did indeed work.

However, having created the CVS checkout, it's easier to issue a
'cvs commit' command directly than to have 'git cvsexportcommit' issue
it for me. I might conclude otherwise if I wanted to keep the git
repository, but these webpages are updated so rarely that I'd rather
just wait and see whether the savannah hackers allow them to be
maintained with git instead of CVS.

(2) Managing the CVS repository directly with a temporary working copy

Because I still don't care to maintain a permanent CVS working copy,
I simply did this:

cd /tmp
mkdir web-cvs
cd web-cvs
cvs -z3 -d "[USER][AT-SIGN]cvs.sv.gnu.org:/web/lmi" checkout lmi
cd lmi

to set up a throwaway copy. Then this command (from (1) above):

GIT_DIR=/tmp/web git cvsexportcommit -vupc -d 
"[USER][AT-SIGN]cvs.sv.gnu.org:/web/lmi" f1759c9

succeeded, but I realized it would be easier to make the next set of
changes directly:

[...change some more files...]
for z in ChangeLog README *.html; do sed -i $z -e '/Copyright/s/2016 Greg/2016, 
2017, 2018 Greg/'; done

/tmp/web-cvs/lmi[0]$cvs -d [USER][AT-SIGN]cvs.sv.gnu.org:/web/lmi commit 
-m'Update copyright notices' '7702.html' 'COPYING.html' 'ChangeLog' 'README' 
'faq.html' 'group_tutorial.html' 'index.html' 'individual_tutorial.html' 
'menu_commands.html' 'pasting_to_a_census.html' 'sequence_input.html' 
'user_manual.html'

Immediately before committing that, I fell back into this git habit:
  /tmp/web-cvs/lmi[0]$cvs diff 2>&1 |less
and had to enter my passphrase again and wait for the server. That's
annoying, though I suppose I could have created another cvs checkout
as a mirror, and used git's diff program for the comparison. And I
could have simplified some of the commands above by configuring some
parameters such as the argument to 'cvs -d'. I'm not so sure I could
use ssh-agent in a chroot; it was very useful with cvs and svn, but
it's not too burdensome to retype a passphrase for a rare 'git push'.
But, again, I think I'll just wait and see whether we'll be able to
use git for the 2019-01-01 webpages update.