Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
> I'm afraid not. It's not really friendly to tarball testers, and at a
> minimum to be helpful to them they shouldn't have to search backward
> past the previous release to find a relevant change.
The ChangeLogs could be generated and included when making a tarball
and the time of the push will define if it is before or after the
Unfortunately, it doesn't work that way. The order in which Mercurial
prints logs is determined by the DAG, and under our commit discipline
we have no mainline. So if we regenerate the log, anything can happen
with older releases, and people with new releases can no longer
communicate with people with older ChangeLogs about such things.
If at each release we try to include only commits since the last
release date, we lose all the commits on branches merged more recently
that were committed before that date. With git, I believe I know how
to script this correctly, but AFAIK Mercurial doesn't expose the
needed plumbing. So somebody would need to write and maintain a
So you can't miss a relevant commit if you base it on what is in
True, but that could require looking arbitrarily far back into the DAG
for the actual commit of interest since merge commit logs are
typically just "Merge."
The problem is when you look into the ChangeLogs and look at the
dates there. They might reflect the time when the developer did the
changelog item which could be before the release giving the false
info that it was part of the release.
Right. That's why the linear order of a ChangeLog is so important,
and there is no good, automated way that I know of to reproduce that
just from the VCS history. Put it this why: this is one reason why
Bazaar fans are so proud of their "mainline orientation", and the
associated disciplines they impose on their development process. Git
fans respond (correctly, IMO) that "bisection is better", but that
requires that the user have git.
> There's no need to abbreviate the per-file comments in a
No but it is not supported by mercurial. IMHO it is actually the
changeset that you should comment and not each file. That is one
important point with atomic commits. If the changes to each file have
different purposes they should be part of different changesets.
Sure. But as far as I can see, the appropriate style is something
Ensure that wadgets are frobbed before being munged.
Tested and documented (closes #DEADBEEF).
(bar) Move call to frob() before mung().
(mung) New final parameter quux, accounts for status return from
(mung) Update parameter list to include quux.
(blatz) Update call to mung() with dummy quux parameter.
Yes. Patcher provides excellent support for this and helps you
those ChangeLogs at commit time. Very useful but to bad that I have
so little luck with it and unfortunately mostly have found it to be in
the way for me. Maybe because I prefer command line tools for doing
the commits or the mercurial mode from within XEmacs.
Sure. That's why I suggest improving add-log and friends. Log
editing support ought to be a separate mode, called from hooks in
VCS-specific modes and Patcher.
I do try to follow the style manually and include the ChangeLogs in
the commit message but that is of course error prone as well.
Another weak spot with ChangeLogs is that you can forget to update
them. I often do. Patcher helps here of course but still it is a
manual thing to update these files.
Sure, like all bureaucracy they're an annoyance when doing "real
work". Thing is, we don't have a replacement as long as we take
tarball distribution seriously.
XEmacs-Beta mailing list