>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
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
release.
So you can't miss a relevant commit if you base it on what is in
mercurial. 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.
There's no need to abbreviate the per-file comments in a
Mercurial
commit.
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.
Didier Verna's Patcher will copy all the logs for a changeset
into the commit message, for example, and it helps to ensure that all
the detail is there.
Yes. Patcher provides excellent support for this and helps you create
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.
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.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta