octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ChangeLogs


From: Jaroslav Hajek
Subject: Re: ChangeLogs
Date: Tue, 6 Jan 2009 07:03:47 +0100

On Tue, Jan 6, 2009 at 6:13 AM, Daniel J Sebald <address@hidden> wrote:
> Jaroslav Hajek wrote:
>>
>> On Mon, Jan 5, 2009 at 5:32 PM, John W. Eaton <address@hidden> wrote:
>>
>>> On  5-Jan-2009, Jaroslav Hajek wrote:
>>>
>>> | Applied.
>>>
>>> Thanks for applying this change.
>>>
>>> It still seems confusing to me that you leave the ChangeLog entry
>>> alone when applying patches.  If I do "hg log" now, I see
>>>
>>> changeset:   8444:c3ac9f2772cd
>>> tag:         tip
>>> user:        Thorsten Meyer <address@hidden>
>>> date:        Mon Jan 05 10:54:22 2009 +0100
>>> summary:     do not eat white space within @example environments of
>>> docstrings
>>>
>>> at the top, but the ChangeLog entry for this change does not have a
>>> Jan 5 date.  Instead, it has a 2008-11-07 date.  If I were looking at
>>> this ChangeLog entry and wanted to find the corresponding changeset,
>>> the date for the ChangeLog entry would not help me find the changeset.
>>> This is why I think we should revise the date of the ChangeLog entry
>>> when checking in changes so that new ChangeLog entries should always
>>> appear at the top of the ChangeLog file.
>>>
>>
>>
>> Sorry, I didn't notice the changelog entry didn't go on top of the
>> file. I do agree that it always should. We should note this in
>> contrib.txi. Mea culpa.
>
> This is the one disadvantage of putting ChangeLog hunks in the patch file.
>  They are almost always rejected because some other entry has already been
> placed at the top.  Anyone know of a command line switch to make diff force
> the hunk to be at the top when patched?
>

No switch, AFAIK. But I've created a patch for Mercurial that accomplishes this
(or handles 99% cases): If a change to a ChangeLog file is detected that only
consists of prepended lines, the diff is done without context (so that
the hunk is
always prepended). Adjusting the date would be nontrivial, however.

> The patch date should be the date the patch was applied, not the date it was
> created, in my opinion.
>

Maybe, but that's way more complicated. Moreover, what if the patch is
transplanted
later to another repo? Should the date of the ChangeLog entries be updated?
Much more work.

>
>>> Or, we should simply decide to do away with ChangeLog files entirely.
>>> But if we do that, I think we should put much more complete commit
>>> messages in the mercurial log files, and we should agree on a common
>>> style for the commit messages.
>
> A few nice things about ChangeLogs:
>
> 1) Legacy and consistency across projects.  I go from one bundled program to
> the next and see ChangeLog, INSTALL, README, and I almost immediately know
> what to do.
>
> 2) ChangeLog can be quickly grepped or searched.  Can source control log
> entries be searched as quickly?
>

Sort of. It can be dumped and then searched.


> 3) Contributors who don't check in stuff can place a ChangeLog entry as a
> hunk in the patch file.
>

Well, you can place the changelog entry in a mercurial patch. Still,
there's one entry
per patch, not per directory, so that's a minor drawback.

> Dan
>



-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


reply via email to

[Prev in Thread] Current Thread [Next in Thread]