< Pod::Thread 1.00 (and spin 1.80) | Russ Allbery > Eagle's Path > January 2013 | Term::ANSIColor 4.02 > |
faq2html is my version of that script that so many different people have written: a tool to convert text files into HTML for the web. This script is specifically tuned to the way that I format text files and has a lot of special logic to deal with my eccentricities, so I have no idea how well it would work for anyone else.
This release adds a new -l
option, which says to add a subheading
to the HTML output giving the last modified date based on the file
modification timestamp. Previously, these subheadings were only added in
some situations and based on RCS/CVS-style Id keywords in the file. Since
I'm converting my personal repositories to Git, that was going to stop
working.
You can get the current version of faq2html from my web tools distribution page.
With this update, I was able to convert my FAQs repository from Subversion to Git, which means that I only have one personal repository left in Subversion (PGP::Sign, which I will probably convert to Git shortly).
That leaves a few CVS repositories, and therein lies a problem.
There are a few places where I'm still using CVS for a conventional package or for some random files, and those can move to Git without much trouble whenever I get around to it. But most of my remaining use of CVS is for storing individual scripts that, if I distribute them at all, I distribute individually. And, for that, CVS seems to have a lot of advantages that are hard to implement with Git:
CVS maintains per-file revision numbers that I can manipulate if I want during check-in. This means that the revision control system maintains a reasonable release version scheme for me without having to do any additional work. I use the CVS-generated version numbers, with the occasional manual bump to a new major revision, for all of my scripts.
CVS Id keywords expose both the version number and last modified date
to the file itself. Nearly all of my scripts have a bit of
boilerplate Perl code that uses this to generate -v
output
showing the version number and last modified date. This is a nice
feature; when you have a running script, you can always figure out its
vintage. Maintaining this information in the script by hand is a
pain.
CVS revision history maps directly to version numbers. This lets me generate, automatically, nice changelog pages like this one for my backport script. Without that concept of per-file version numbers for a script repository, I would have to determine the mapping of changes to version numbers manually somehow.
I'm not at all sure what I'm going to do about this. Some of my scripts currently maintained in CVS, such as all the AFS tools, should move into larger packages that are more conventionally distributed, with a separate README file and similar machinery, and I'm slowly in the process of doing that. But many of my scripts are small programs that don't fit into any larger whole and don't warrant that sort of treatment.
Honestly, I'm moderately tempted to just keep using CVS for scripts, since everything newer goes to repository-wide instead of per-file version numbers (for exceptionally good reasons when working on a unified piece of software, rather than a conglomeration of individual scripts), and I'm unenthused about writing my own machinery using Git hooks and smart Git log and diff parsing. But the CVS command-line interface is awful and the CVS repository format is even worse.
If there are any brilliant ideas that I'm missing, I'd be interested in hearing about them in email (or other blog posts on Planet Debian or somewhere else I read). If I come up with some solution or get any great advice, I'll post a follow-up.
Posted: 2013-01-06 16:59 — Why no comments?
< Pod::Thread 1.00 (and spin 1.80) | Russ Allbery > Eagle's Path > January 2013 | Term::ANSIColor 4.02 > |