-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Karl Berry wrote: > I don't think it's exactly "recommended"; it's mentioned as an > alternative, but in a rather ambiguous way (at least if we're talking > about the same thing, in the Change Log Concepts node of standards.texi): > > Another alternative is to record change log information with a > version control system such as RCS or CVS. This can be converted > automatically to a `ChangeLog' file using `rcs2log'; ....
Yup, that's it. I'm not sure how it's ambiguous, though. > Personally, as is somewhat implied here, I think it is highly desirable > for there to be actual ChangeLog files in distributions, at least, > independent of whether they are created from the vc logs. Sure. I don't think anyone was saying otherwise. > For background: I believe that rms relies on ChangeLog files in his > distributions for legal information. That's why the whole "(tiny > change)" stuff exists, why the rules for who is given as the author are > spelled out so precisely (Style of Change Logs), etc. In the vc logs, > the person who commits the change might not be the person who wrote the > change. What matters legally is who wrote it. That's an important point, and one I'd thought about. I figured, though, that where useful, someone could use some notation within the commit log to indicate that a different user should be credited. OTOH, a more difficult problem might be: how do you go about fixing erroneous commit logs? In Subversion and CVS, this can be dealt with if you have appropriate privileges; but in Mercurial at least (and probably Git as well?), the commit log is a part of the changeset; you can't change it without making it a wholly separate changeset. So if it's already been published, it'd be impractical to correct; it'd require some gnarly post-processing, then, to make the corrections. Then again, there's a different sort of problem that's been irking me somewhat with making ChangeLog entries (whether generated or manual), ever since I started using DRCSses, and that is that the DAG nature of change history in a DRCS doesn't map cleanly to a linear ChangeLog. That is, you can no longer depend, for changes listed A, B, C, D, that all of the changes A, B, and C were present at the time change D was made. This can lead to false impressions about the context of a change entry, or of the history of a particular section of code. This isn't causing me major headaches, but then again, that's probably because I rely much more heavily on the RCS's logs rather than ChangeLog files. I suspect the time may be coming to discuss extensions to the canonical ChangeLog format that would allow it to describe the source history in it's DAG form. Though, I suppose simply complimenting the existing ChangeLog with an alternate-format changelog taken straight from git or Mercurial, including changeset parentage information, would be an acceptable way of dealing with this. Mercurial's text-based "graphlog" extension might do well for this (see http://www.selenic.com/mercurial/wiki/index.cgi/GraphlogExtension for sample output). - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHsQdL7M8hyUobTrERAjj6AJ9lfe+4yEkY68NHIf0g3MpW2tILfQCfbkks EXeAofXGnCVOuLNjKBPW+Q8= =jA0+ -----END PGP SIGNATURE-----
