A little suggestion

A little suggestion

[Angelo Graziosi]

In Emacs, Help | About Emacs, there is written:

"GNU Emacs 23.1.91.1 (i686-pc-cygwin, GTK+ Version 2.18.3)
  of 2010-01-05 on..."

Why, in the development stage, not adding the revision number? i.e.:

"GNU Emacs 23.1.91.1 rev. 99259..."

In GCC, for example, this happens.


Ciao,
Angelo.

Re: A little suggestion

[Lennart Borgman]

On Tue, Jan 5, 2010 at 11:35 AM, Angelo Graziosi
<angelo.graziosi@alice.it> wrote:
> In Emacs, Help | About Emacs, there is written:
>
> "GNU Emacs 23.1.91.1 (i686-pc-cygwin, GTK+ Version 2.18.3)
>  of 2010-01-05 on..."
>
> Why, in the development stage, not adding the revision number? i.e.:
>
> "GNU Emacs 23.1.91.1 rev. 99259..."
>
> In GCC, for example, this happens.


I wonder if it is possible? Is it well defined?

Perhaps the beginning and ending time of the checkout could be used
instead? But I wonder if they are available either.

Re: A little suggestion

[Angelo Graziosi]

Il 05/01/2010 11.40, Lennart Borgman ha scritto:
> On Tue, Jan 5, 2010 at 11:35 AM, Angelo Graziosi
> <angelo.graziosi@alice.it>  wrote:
>> In Emacs, Help | About Emacs, there is written:
>>
>> "GNU Emacs 23.1.91.1 (i686-pc-cygwin, GTK+ Version 2.18.3)
>>   of 2010-01-05 on..."
>>
>> Why, in the development stage, not adding the revision number? i.e.:
>>
>> "GNU Emacs 23.1.91.1 rev. 99259..."
>>
>> In GCC, for example, this happens.
>
>
> I wonder if it is possible? Is it well defined?
>
> Perhaps the beginning and ending time of the checkout could be used
> instead? But I wonder if they are available either.

Shouldn't writing 'rev. 99259' in some .bzr files be enough? For 
example, when building, if it finds 'rev. 99259', it generates:

"GNU Emacs 23.1.91.1 rev. 99259..."

else if it finds 'release', it gives:

"GNU Emacs 23.2 release..."

I am sure Emacs guys have better ideas. :-)


Thanks,
Angelo.

Re: A little suggestion

[Sven Joachim]

On 2010-01-05 11:40 +0100, Lennart Borgman wrote:

> On Tue, Jan 5, 2010 at 11:35 AM, Angelo Graziosi
> <angelo.graziosi@alice.it> wrote:
>> In Emacs, Help | About Emacs, there is written:
>>
>> "GNU Emacs 23.1.91.1 (i686-pc-cygwin, GTK+ Version 2.18.3)
>>  of 2010-01-05 on..."
>>
>> Why, in the development stage, not adding the revision number? i.e.:
>>
>> "GNU Emacs 23.1.91.1 rev. 99259..."
>>
>> In GCC, for example, this happens.
>
>
> I wonder if it is possible?

Certainly, you just need to run "bzr revno" during the build and dump
the result into Emacs.

> Is it well defined?

Not very well, if you have local commits it can be misleading.  And
there is the problem that not all changes lead to re-dumping Emacs.
Running "bzr revno" at bug commit time will not always work either.

Sven

Re: A little suggestion

[Giorgos Keramidas]

On Tue, 5 Jan 2010 11:40:36 +0100, Lennart Borgman <lennart.borgman@gmail.com> wrote:
> On Tue, Jan 5, 2010 at 11:35 AM, Angelo Graziosi
> <angelo.graziosi@alice.it> wrote:
>> In Emacs, Help | About Emacs, there is written:
>>
>> "GNU Emacs 23.1.91.1 (i686-pc-cygwin, GTK+ Version 2.18.3)
>>  of 2010-01-05 on..."
>>
>> Why, in the development stage, not adding the revision number? i.e.:
>>
>> "GNU Emacs 23.1.91.1 rev. 99259..."
>>
>> In GCC, for example, this happens.
>
> I wonder if it is possible? Is it well defined?
>
> Perhaps the beginning and ending time of the checkout could be used
> instead? But I wonder if they are available either.

A revision number like 2100 is *not* well-defined in a DVCS.  But there
is a revision identifier that includes a hash we could probably use:

% keramida@kobe:/bzr/emacs/gker$ bzr log --limit 1 --show-ids .
% ------------------------------------------------------------
% revno: 99248
% revision-id: eliz@gnu.org-20100102213336-hnnaav0wq0al1gni
% ...

The `revision-id' value is arguably something that may be useful to have
in `M-x emacs-version' output.  At least for non-release builds of Emacs.

A little suggestion

[Stephen J. Turnbull]

Angelo Graziosi writes:

 > Why, in the development stage, not adding the revision number? i.e.:
 > 
 > "GNU Emacs 23.1.91.1 rev. 99259..."

Revision numbers are not globally defined in bzr; they mean different
things in different branches.  There is a global revision ID, but it's
typically at least 40 characters long, sometimes a fair amount more.

Re: A little suggestion

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Tue, 05 Jan 2010 20:23:27 +0900
> Cc: Emacs <emacs-devel@gnu.org>
> 
> There is a global revision ID, but it's typically at least 40
> characters long, sometimes a fair amount more.

Part of that is the email address of the committer, the other part is
the time of the commit in second resolution, and only the last part,
16 characters in my case, is a meaningless string (which is probably
an ASCII encoding of a number).  So we could display the global revid
as something palatable, if not exactly short.

<shrug> Not that I understand why this would be useful...

Re: A little suggestion

[Lennart Borgman]

On Tue, Jan 5, 2010 at 8:24 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: "Stephen J. Turnbull" <stephen@xemacs.org>
>> Date: Tue, 05 Jan 2010 20:23:27 +0900
>> Cc: Emacs <emacs-devel@gnu.org>
>>
>> There is a global revision ID, but it's typically at least 40
>> characters long, sometimes a fair amount more.
>
> Part of that is the email address of the committer, the other part is
> the time of the commit in second resolution, and only the last part,
> 16 characters in my case, is a meaningless string (which is probably
> an ASCII encoding of a number).  So we could display the global revid
> as something palatable, if not exactly short.
>
> <shrug> Not that I understand why this would be useful...

I don't think it will. Check out time is much more easy to understand
and compare.

Re: A little suggestion

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> There is a global revision ID, but it's typically at least 40
>> characters long, sometimes a fair amount more.
>
> Part of that is the email address of the committer, the other part is
> the time of the commit in second resolution, and only the last part,
> 16 characters in my case, is a meaningless string (which is probably
> an ASCII encoding of a number).  So we could display the global revid
> as something palatable, if not exactly short.
>
> <shrug> Not that I understand why this would be useful...

It potentially allows to replicate the exact state of the sources used
for building emacs (suppossing that they didn't contained uncommitted
changes.)

Very useful on bug reports.

-- 
Óscar

Re: A little suggestion

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > So we could display the global revid as something palatable, if not
 > exactly short.
 > 
 > <shrug> Not that I understand why this would be useful...

You can ask bzr to search for it, and if it's not in the Emacs
repository, you know the user has local changes, and you can even ask
for an exact diff.  (You would also need to check bzr status for
uncommitted changes.)

Seems to me that this is about as useful as the rest of the
information generated by M-x report-emacs-bug.