ChangeLog entry timestamp

ChangeLog entry timestamp

[Vinicius Jose Latorre]

Hi,


I've just noticed that entries timestamp in ChangeLog (trunk and Emacs 
22 branch) are unsorted, that is, there are entries as:

2007-08-03 ...
2007-08-02 ...
2007-07-31 ...   <<<
2007-08-03 ...   <<<
2007-08-01 ...
2007-07-31 ...
2007-07-29 ...
2007-07-28 ...
2007-07-30 ...   <<<
2007-07-29 ...   <<<
2007-07-28 ...
2007-07-27 ...
2007-07-26 ...
2007-07-25 ...
2007-07-24 ...
2007-07-25 ...   <<<
2007-07-24 ...
2007-07-23 ...
2007-07-20 ...   <<<
2007-07-23 ...
2007-07-22 ...
etc.


Is this a problem?  Should the entries be sorted?


Vinicius

Re: ChangeLog entry timestamp

[David Kastrup]

Vinicius Jose Latorre <viniciusjl@ig.com.br> writes:

> I've just noticed that entries timestamp in ChangeLog (trunk and Emacs
> 22 branch) are unsorted, that is, there are entries as:
>
> 2007-08-03 ...
> 2007-08-02 ...
> 2007-07-31 ...   <<<
> 2007-08-03 ...   <<<
> 2007-08-01 ...
> 2007-07-31 ...
> 2007-07-29 ...
> 2007-07-28 ...
> 2007-07-30 ...   <<<
> 2007-07-29 ...   <<<
> 2007-07-28 ...
> 2007-07-27 ...
> 2007-07-26 ...
> 2007-07-25 ...
> 2007-07-24 ...
> 2007-07-25 ...   <<<
> 2007-07-24 ...
> 2007-07-23 ...
> 2007-07-20 ...   <<<
> 2007-07-23 ...
> 2007-07-22 ...
> etc.
>
>
> Is this a problem?  Should the entries be sorted?

No.  The dates are when the patches have been created, the order is
according to when they have been committed.  Even if people would
always commit immediately, we would not get calendar linearity because
of differing timezones.

-- 
David Kastrup

Re: ChangeLog entry timestamp

[Stefan Monnier]

>> I've just noticed that entries timestamp in ChangeLog (trunk and Emacs
>> 22 branch) are unsorted, that is, there are entries as:
>> 
>> 2007-08-03 ...
>> 2007-08-02 ...
>> 2007-07-31 ...   <<<
>> 2007-08-03 ...   <<<
>> 2007-08-01 ...
>> 2007-07-31 ...
>> 2007-07-29 ...
>> 2007-07-28 ...
>> 2007-07-30 ...   <<<
>> 2007-07-29 ...   <<<
>> 2007-07-28 ...
>> 2007-07-27 ...
>> 2007-07-26 ...
>> 2007-07-25 ...
>> 2007-07-24 ...
>> 2007-07-25 ...   <<<
>> 2007-07-24 ...
>> 2007-07-23 ...
>> 2007-07-20 ...   <<<
>> 2007-07-23 ...
>> 2007-07-22 ...
>> etc.
>> 
>> Is this a problem?  Should the entries be sorted?

> No.  The dates are when the patches have been created, the order is
> according to when they have been committed.

Actually, the date should be the date it was committed, so it should
be sorted.  Not sure about what should happen in case of merges, tho.

> Even if people would always commit immediately, we would not get calendar
> linearity because of differing timezones.

We've switched to UTC times some months (year?) ago, so this shouldn't be an
issue any more.


        Stefan

Re: ChangeLog entry timestamp

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Actually, the date should be the date it was committed, so it should
> be sorted.

Wishful thinking.  Sorting the entries without sorting the
corresponding commits is going to make an even greater mess.

> Not sure about what should happen in case of merges, tho.
>
>> Even if people would always commit immediately, we would not get calendar
>> linearity because of differing timezones.
>
> We've switched to UTC times some months (year?) ago, so this
> shouldn't be an issue any more.

Huh?  Everybody creates his ChangeLog entry on his own.  And not
everybody's computer runs on UTC.

-- 
David Kastrup

Re: ChangeLog entry timestamp

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Huh?  Everybody creates his ChangeLog entry on his own.  And not
> everybody's computer runs on UTC.

;; Local Variables:
;; coding: iso-2022-7bit
;; add-log-time-zone-rule: t
;; End:

t means UTC.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ChangeLog entry timestamp

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Actually, the date should be the date it was committed, so it should
> be sorted.  Not sure about what should happen in case of merges, tho.

I think because of merges, things are always basically going to be a bit
screwed up.  There's no perfect solution.

I'd suggest the best thing would be to relax and not worry about
slightly misordered timestamps on entries.  It's not a big deal.

-Miles
-- 
The key to happiness
 is having dreams.	[from a fortune cookie]

Re: ChangeLog entry timestamp

[Jason Rumney]

David Kastrup wrote:
> Huh?  Everybody creates his ChangeLog entry on his own.

If you use add-change-log-entry, it will DTRT.

Re: ChangeLog entry timestamp

[Richard Stallman]

    Actually, the date should be the date it was committed, so it should
    be sorted.  Not sure about what should happen in case of merges, tho.

A merge into the trunk should be treated like any other installation
into the trunk.  The change log entries should look the same as they
would if the changes had been installed some other way.

This is because, that if you are merging into the trunk, you should
combine and simplify the change log entries.

Re: ChangeLog entry timestamp

[Richard Stallman]

    > Actually, the date should be the date it was committed, so it should
    > be sorted.

    Wishful thinking.  Sorting the entries without sorting the
    corresponding commits is going to make an even greater mess.

The rule is simple.  You should put every entry at the front of the
change log file, with the current UTC date.

The only reason to insert an entry other than at the front of
ChangeLog is if you checked in the change previously and you forgot to
add the change log entry at the same time.