`about-emacs' - what about the revno?

`about-emacs' - what about the revno?

[Drew Adams]

When a bug that I filed gets fixed, sometimes the developer who fixes it lets me
know which "revno" it is fixed in.  E.g. "This bug is now fixed (revno 101110)."

I do not build Emacs myself, and I have no idea what the "revno" corresponds to
or how/where to find it in an existing Emacs build (binary).

When I do `C-h C-a', or when I submit a bug, I see only an identifier like this:

GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-08-16 on 3249CTO

If the "revno" is important info for identifying an Emacs build, then perhaps we
should include it in such user-facing info.  If not, then perhaps developers
could refer in some other way (by date?) to the code that contains a given fix.

Re: `about-emacs' - what about the revno?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 28 Aug 2010 08:38:15 -0700
> 
> When a bug that I filed gets fixed, sometimes the developer who fixes it lets me
> know which "revno" it is fixed in.  E.g. "This bug is now fixed (revno 101110)."
> 
> I do not build Emacs myself, and I have no idea what the "revno" corresponds to
> or how/where to find it in an existing Emacs build (binary).
> 
> When I do `C-h C-a', or when I submit a bug, I see only an identifier like this:
> 
> GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
>  of 2010-08-16 on 3249CTO
> 
> If the "revno" is important info for identifying an Emacs build, then perhaps we
> should include it in such user-facing info.  If not, then perhaps developers
> could refer in some other way (by date?) to the code that contains a given fix.

This has come up before, but the discussion was inconclusive (IIRC)
because of 2 reasons:

  . revno is not unique: two different branches can have the same
    revno for two very different code bases

  . revision-id, an alternative method of specifying a revision, _is_
    unique, but it's long and a mouthful:

            eliz@gnu.org-20100828152310-v42vqrt01k788siu

In general, a bugfix should appear in the ChangeLog files with the bug
number, so you should be able to track bugfxes that way.

RE: `about-emacs' - what about the revno?

[Drew Adams]

> > If the "revno" is important info for identifying an Emacs 
> > build, then perhaps we should include it in such user-facing info.
> >
> > If not, then perhaps developers could refer in some other
> > way (by date?) to the code that contains a given fix.
> 
> This has come up before, but the discussion was inconclusive (IIRC)
> because of 2 reasons:
> 
>   . revno is not unique: two different branches can have the same
>     revno for two very different code bases
> 
>   . revision-id, an alternative method of specifying a revision, _is_
>     unique, but it's long and a mouthful:
> 
>             eliz@gnu.org-20100828152310-v42vqrt01k788siu
> 
> In general, a bugfix should appear in the ChangeLog files with the bug
> number, so you should be able to track bugfxes that way.

OK, thanks.

But please see the "If not..." part above.  I am interested in knowing which
upcoming Windows binary will have a particular fix (e.g. identified by "revno
101110").  When communicating with bug-report filers, a date is perhaps more
useful than just a revno (and users should not need to dig into change logs).
Some users might be able to do something with a revno, but a date should be of
some help to any user.

Re: `about-emacs' - what about the revno?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Sat, 28 Aug 2010 09:05:54 -0700
> 
> But please see the "If not..." part above.  I am interested in knowing which
> upcoming Windows binary will have a particular fix (e.g. identified by "revno
> 101110").  When communicating with bug-report filers, a date is perhaps more
> useful than just a revno (and users should not need to dig into change logs).
> Some users might be able to do something with a revno, but a date should be of
> some help to any user.

The bug database shows a date when the bug was fixed, doesn't it?  I'm
assuming, perhaps incorrectly, that the person who commits the fix for
a bug sends a mail to the bug tracker on the same day.

Re: `about-emacs' - what about the revno?

[Jason Rumney]

  On 29/8/2010 12:05 AM, Drew Adams wrote:
>>> If not, then perhaps developers could refer in some other
>>> way (by date?) to the code that contains a given fix.
>>
> But please see the "If not..." part above.  I am interested in knowing which
> upcoming Windows binary will have a particular fix (e.g. identified by "revno
> 101110").  When communicating with bug-report filers, a date is perhaps more
> useful than just a revno (and users should not need to dig into change logs).
> Some users might be able to do something with a revno, but a date should be of
> some help to any user.

Perhaps you could use the date that the email was sent?

Re: `about-emacs' - what about the revno?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>   . revision-id, an alternative method of specifying a revision, _is_
>     unique, but it's long and a mouthful:
>
>             eliz@gnu.org-20100828152310-v42vqrt01k788siu

Even if that is a mouthful, why not include it on M-x report-emacs-bug?

Re: `about-emacs' - what about the revno?

[Christoph]

On 8/28/2010 9:57 AM, Eli Zaretskii wrote:

>> If the "revno" is important info for identifying an Emacs build, then perhaps we
>> should include it in such user-facing info.  If not, then perhaps developers
>> could refer in some other way (by date?) to the code that contains a given fix.
>
> This has come up before, but the discussion was inconclusive (IIRC)
> because of 2 reasons:
>
>    . revno is not unique: two different branches can have the same
>      revno for two very different code bases
>
>    . revision-id, an alternative method of specifying a revision, _is_
>      unique, but it's long and a mouthful:
>
>              eliz@gnu.org-20100828152310-v42vqrt01k788siu
>
> In general, a bugfix should appear in the ChangeLog files with the bug
> number, so you should be able to track bugfxes that way.

I too think having the revision available somewhere would be helpful to 
identify the weekly snapshot builds. Just a date is too coarse in some 
cases, imho.

The revno is indeed not unique globally, but if the branch is known, it 
is, right? So, why don't we supply to pieces of information: the revno 
and the name of the branch, e.g. the branch nick (available through bzr 
version-info).

For Windows, we could implement another make target, e.g. make snapshot, 
which uses make dist (for building the binary distribution) but also 
inserts the revno and branch nick information somewhere. I am not sure 
how useful this information is for official releases, but if it is 
considered useful, we can just add this to make dist even.

I like the combination of revno and branch name better than the 
revision-id. It seems easier to correlate these with the current state 
of the trunk using bzr log.

Christoph

Re: `about-emacs' - what about the revno?

[Teemu Likonen]

* 2010-08-28 18:57 (+0300), Eli Zaretskii wrote:

> "Drew Adams" wrote:
>> If the "revno" is important info for identifying an Emacs build, then
>> perhaps we should include it in such user-facing info. If not, then
>> perhaps developers could refer in some other way (by date?) to the
>> code that contains a given fix.
>
> This has come up before, but the discussion was inconclusive (IIRC)
> because of 2 reasons:
>
>   . revno is not unique: two different branches can have the same
>     revno for two very different code bases
>
>   . revision-id, an alternative method of specifying a revision, _is_
>     unique, but it's long and a mouthful:
>
>             eliz@gnu.org-20100828152310-v42vqrt01k788siu

Another reason to use Git instead. With "git describe" you get unique
commit identifiers which are also human-readable and have an increasing
commit counter in it, for example:

    v23.2-54-g1234ab

It consists of the latest tag name (e.g., "v23.2") which is reachable
from the current commit, the commit count (54) after the tag and an
abbreviated SHA1 ID of the current commit (1234ab).

Some projects that use Git include such a version string automatically
to program's build. Git commands understand the string as a version
identifier. When executing "git describe" on a tagged commit it outputs
just the tag name (e.g., "v23.2") so it automatically gives the right
answer for releases too (can be useful when creating release tarballs).

Sorry for pushing Git again but it's just better.

> In general, a bugfix should appear in the ChangeLog files with the bug
> number, so you should be able to track bugfxes that way.

More elegant way is to write something like "Closes: bug#1234" in the
appropriate commit message and have the central Emacs repository use a
post-receive hook script that will detect the keyword in commit
messages. The hook script could then send control message to the bug
tracker and close the bug with a message like this:

    This issue has been fixed by the commit

        Commit: v23.2-57-gab1cd2
        Author: Dave Developer <email@internet.invalid>
        Date:   2010-00-00 00:00:00 +0000

    You can use command "git show v23.2-57-gab1cd2" in the Emacs Git
    repository to see the details.

Re: `about-emacs' - what about the revno?

[Stefan Monnier]

> This has come up before, but the discussion was inconclusive (IIRC)
> because of 2 reasons:

>   . revno is not unique: two different branches can have the same
>     revno for two very different code bases

Maybe we should try and provide the revno of the common ancestor on
the trunk.  I only see two problems with it:
1- you'll probably need Internet access to find this info (might be
   problematic during a build, for instance).
2- I don't know how to tell Bzr to give me this info.


        Stefan

Re: `about-emacs' - what about the revno?

[Lennart Borgman]

On Mon, Aug 30, 2010 at 5:41 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> This has come up before, but the discussion was inconclusive (IIRC)
>> because of 2 reasons:
>
>>   . revno is not unique: two different branches can have the same
>>     revno for two very different code bases
>
> Maybe we should try and provide the revno of the common ancestor on
> the trunk.  I only see two problems with it:
> 1- you'll probably need Internet access to find this info (might be
>   problematic during a build, for instance).
> 2- I don't know how to tell Bzr to give me this info.

I use this in my patched version of Emacs (on w32):


  bzr version-info --custom --template "(defconst
emacs-emacsw32-bzr-revision-id \"{revision_id}\")\n"
  bzr version-info --custom --template "(defconst
emacs-emacsw32-bzr-date \"{date}\")\n"
  bzr version-info --custom --template "(defconst
emacs-emacsw32-bzr-revno {revno})\n"
  bzr version-info --custom --template "(defconst
emacs-emacsw32-bzr-branch-nick \"{branch_nick}\")\n"

and then I save this to a file which I read in Emacs.

Re: `about-emacs' - what about the revno?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Drew Adams <drew.adams@oracle.com>,  emacs-devel@gnu.org
> Date: Mon, 30 Aug 2010 17:41:28 +0200
> 
> Maybe we should try and provide the revno of the common ancestor on
> the trunk.  I only see two problems with it:
> 1- you'll probably need Internet access to find this info (might be
>    problematic during a build, for instance).
> 2- I don't know how to tell Bzr to give me this info.

The answer to 2 is "bzr version-info", it accepts options that define
the format in which to produce the output.  Unfortunately, in a bound
branch it hits the network.  Maybe we should ask Bazaar developers to
add a --local switch.

Re: `about-emacs' - what about the revno?

[Eli Zaretskii]

> Date: Mon, 30 Aug 2010 19:27:44 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: Drew Adams <drew.adams@oracle.com>,  emacs-devel@gnu.org
> > Date: Mon, 30 Aug 2010 17:41:28 +0200
> > 
> > Maybe we should try and provide the revno of the common ancestor on
> > the trunk.  I only see two problems with it:
> > 1- you'll probably need Internet access to find this info (might be
> >    problematic during a build, for instance).
> > 2- I don't know how to tell Bzr to give me this info.
> 
> The answer to 2 is "bzr version-info", it accepts options that define
> the format in which to produce the output.  Unfortunately, in a bound
> branch it hits the network.  Maybe we should ask Bazaar developers to
> add a --local switch.

Actually, in the trunk we don't need anything but the revno, right?
So the question is how to find the revno of the trunk from which the
current branch branched, right?

How about "bzr log --short -r ancestor:../trunk", then take only the
revno from the result?  The only problem is that this is quite slow:
it takes 21 seconds on my Windows XP box and 11 seconds on fencepost,
and that's with a warm cache -- probably too long for doing that
during the build.

Re: `about-emacs' - what about the revno?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Actually, in the trunk we don't need anything but the revno, right?

As far as it does not change, as it did on the past...

> So the question is how to find the revno of the trunk from which the
> current branch branched, right?

How is it useful to know the common ancestor with the trunk? Does it
help when the user is working with a branch containing local commits, or
with the clone of a feature branch?

[snip]

Re: `about-emacs' - what about the revno?

[Stefan Monnier]

>> Actually, in the trunk we don't need anything but the revno, right?
> As far as it does not change, as it did on the past...

Supposedly it can't happen again.  In any case, if it does, it's
a problem in itself, so it's not relevant to this issue.

>> So the question is how to find the revno of the trunk from which the
>> current branch branched, right?
> How is it useful to know the common ancestor with the trunk? Does it
> help when the user is working with a branch containing local commits, or
> with the clone of a feature branch?

Yes, it helps to know which patches from trunk are in his branch.
Of course, there's still the unknown of his local patches, but that's
another issue (we can add a "bzr diff -r ancestro:... | wc" to the
revno info to indicate how far it is to the vanilla code).


        Stefan

Re: `about-emacs' - what about the revno?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> How about "bzr log --short -r ancestor:../trunk",

How do you find out "../trunk"?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: `about-emacs' - what about the revno?

[Stefan Monnier]

>> How about "bzr log --short -r ancestor:../trunk",
> How do you find out "../trunk"?

You search for "http emacs bzr trunk" and voilà:

   http://bzr.savannah.gnu.org/r/emacs/trunk


-- Stefan


PS: As mentioned earlier, it requires internet access.

Re: `about-emacs' - what about the revno?

[Andreas Schwab]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> PS: As mentioned earlier, it requires internet access.

I thought bzr is a dVCS?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: `about-emacs' - what about the revno?

[Stefan Monnier]

>> PS: As mentioned earlier, it requires internet access.
> I thought bzr is a dVCS?

Yes, but we want to relate someone's code to the one in our repository.
Admittedly, with Arch we could rely on the globally unique branch names
to use the user's local mirror, but with Bzr, there's no such thing.
I'm not sure how we'd do it with Git, actually (we could presume the
user follows some kind of convention w.r.t naming of his copy of the
trunk, I guess).


        Stefan

Re: `about-emacs' - what about the revno?

[Óscar Fuentes]

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

>>> PS: As mentioned earlier, it requires internet access.
>> I thought bzr is a dVCS?
>
> Yes, but we want to relate someone's code to the one in our
> repository.

The question here is: are you interested on bug reports coming from
builds that contains unknown modifications?

If yes, well, use the revno of the common ancestor with trunk (if you
figure out a good way to obtain it.)

Otherwise, you *really* want the revision-id.

(I guess that at some point into the future bug reports for sanctioned
feature branches will be accepted too. Then, the "common ancestor with
trunk" approach will need an overhaul. Using the revision-id of the
common ancestor with the parent branch on Savannha would help on that
scenario. Plus the revision-id of the tip of the user's branch, for
knowing if he has local commits.)

[snip]

Re: `about-emacs' - what about the revno?

[Stefan Monnier]

>>>> PS: As mentioned earlier, it requires internet access.
>>> I thought bzr is a dVCS?
>> Yes, but we want to relate someone's code to the one in our
>> repository.
> The question here is: are you interested on bug reports coming from
> builds that contains unknown modifications?

Not terribly, but we have handled some such reports in the past (Debian
and a few others come to mind).  And I think we want to encourage people
to develop local patches in their local branches (with the hope they'll
contribute them eventually), as well as encourage people to report bugs,
so yes, I think we are interested.  We usually accept the report, tho we
also often ask people to try and reproduce the bug on a vanilla build.

> (I guess that at some point into the future bug reports for sanctioned
> feature branches will be accepted too.

Actually, that's already the case since we have both the trunk and the
emacs-23 branch (not exactly "feature branches", but the problem is the
same).

> Then, the "common ancestor with trunk" approach will need an overhaul.

It already does.  We want "nick+revno+changes" where "nick" is the name
of one of the branches in our repository and "changes" is some
representation of the changes relative to "nick+revno".  Can be just
a boolean indicating whether there are changes, or it could be something
else like the "bzr diff|wc" I suggested.


        Stefan

Re: `about-emacs' - what about the revno?

[Miles Bader]

Andreas Schwab <schwab@linux-m68k.org> writes:
>> PS: As mentioned earlier, it requires internet access.
>
> I thought bzr is a dVCS?

It's a floor wax _and_ a dessert topping!

-miles

-- 
It wasn't the Exxon Valdez captain's driving that caused the Alaskan oil spill.
It was yours.  [Greenpeace advertisement, New York Times, 25 February 1990]

Re: `about-emacs' - what about the revno?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Tue, 31 Aug 2010 12:35:37 +0200
> 
> >> How about "bzr log --short -r ancestor:../trunk",
> > How do you find out "../trunk"?
> 
> You search for "http emacs bzr trunk" and voilà:
> 
>    http://bzr.savannah.gnu.org/r/emacs/trunk

There's an easier way: in .bzr/branc/branch.conf we have this line:

  parent_location = ../trunk/

> PS: As mentioned earlier, it requires internet access.

The above way doesn't (for local branches).

Re: `about-emacs' - what about the revno?

[Stefan Monnier]

>> You search for "http emacs bzr trunk" and voilà:
>> http://bzr.savannah.gnu.org/r/emacs/trunk
> There's an easier way: in .bzr/branc/branch.conf we have this line:
>   parent_location = ../trunk/

The parent branch of my main work branch is not "trunk", so while this
may work for your particular workflow, it won't DTRT for all workflows.

>> PS: As mentioned earlier, it requires internet access.
> The above way doesn't (for local branches).

Clearly, we can expect the user to have copy of the trunk in his local
repository, but Bzr doesn't make it easy for us to figure out its
local name in a reliable way.

I reported this problem to the bazaar list a while back for the specific
case of "bzr diff -rsubmit:", but it goes further indeed.


        Stefan

Re: `about-emacs' - what about the revno?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: schwab@linux-m68k.org,  emacs-devel@gnu.org
> Date: Wed, 01 Sep 2010 08:25:07 +0200
> 
> >> You search for "http emacs bzr trunk" and voilà:
> >> http://bzr.savannah.gnu.org/r/emacs/trunk
> > There's an easier way: in .bzr/branc/branch.conf we have this line:
> >   parent_location = ../trunk/
> 
> The parent branch of my main work branch is not "trunk", so while this
> may work for your particular workflow, it won't DTRT for all workflows.

But then what exactly is the definition of "ancestor"?  I took it in
bzr terms for the current branch, but now it seems you had something
different in mind.  What is it?

Re: `about-emacs' - what about the revno?

[Stefan Monnier]

>> >> You search for "http emacs bzr trunk" and voilà:
>> >> http://bzr.savannah.gnu.org/r/emacs/trunk
>> > There's an easier way: in .bzr/branc/branch.conf we have this line:
>> >   parent_location = ../trunk/
>> The parent branch of my main work branch is not "trunk", so while this
>> may work for your particular workflow, it won't DTRT for all workflows.
> But then what exactly is the definition of "ancestor"?  I took it in
> bzr terms for the current branch, but now it seems you had something
> different in mind.  What is it?

The same definition as the one for "-r ancestor:...", i.e. an ancestor
of the current revision is a revision that's part of the current
revision's history.

And what I want is the nearest ancestor that's on one of the branches
hosted in bzr.sv.gnu.org.  And for convenience's sake, I'd like this
ancestor to be described not by a revision-id but by a "branchname+revno".


        Stefan

Re: `about-emacs' - what about the revno?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: schwab@linux-m68k.org,  emacs-devel@gnu.org
> Date: Wed, 01 Sep 2010 09:45:22 +0200
> 
> >> >> You search for "http emacs bzr trunk" and voilà:
> >> >> http://bzr.savannah.gnu.org/r/emacs/trunk
> >> > There's an easier way: in .bzr/branc/branch.conf we have this line:
> >> >   parent_location = ../trunk/
> >> The parent branch of my main work branch is not "trunk", so while this
> >> may work for your particular workflow, it won't DTRT for all workflows.
> > But then what exactly is the definition of "ancestor"?  I took it in
> > bzr terms for the current branch, but now it seems you had something
> > different in mind.  What is it?
> 
> The same definition as the one for "-r ancestor:...", i.e. an ancestor
> of the current revision is a revision that's part of the current
> revision's history.

I'm confused: there are any number of revisions that match this
definition.  You wanted just one.

Put it another way: AFAIU, "-r ancestor:" _requires_ a branch
specifier.  Which branch do you want to specify there?  I assumed it
was the parent of the current branch.  If you want the trunk instead,
we could either use http://bzr.savannah.gnu.org/r/emacs/trunk
(requires a live connection and Savannah being up) or we could chase
the parent pointers until we find a branch whose parent is on
Savannah.

But it sounds like this is academic: it will be too slow to be a part
of the build, because "bzr version-info" is slow.

Re: `about-emacs' - what about the revno?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Tue, 31 Aug 2010 12:35:37 +0200
> 
> >> How about "bzr log --short -r ancestor:../trunk",
> > How do you find out "../trunk"?
> 
> You search for "http emacs bzr trunk" and voilà:
> 
>    http://bzr.savannah.gnu.org/r/emacs/trunk

In addition to what I wrote earlier, we could simply call "bzr info"
and look for a line that starts with "parent branch".

Re: `about-emacs' - what about the revno?

[Óscar Fuentes]

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

>> This has come up before, but the discussion was inconclusive (IIRC)
>> because of 2 reasons:
>
>>   . revno is not unique: two different branches can have the same
>>     revno for two very different code bases
>
> Maybe we should try and provide the revno of the common ancestor on
> the trunk.

That information only makes sense for mirrors of trunk.

The revision-id is the real info. The fact that it is inconvenient to
handle is no excuse for doing the wrong thing. And revnos are definitely
the wrong thing to look at when determining which source code was used
for a build.

[snip]

Re: `about-emacs' - what about the revno?

[Lennart Borgman]

On Mon, Aug 30, 2010 at 7:39 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> This has come up before, but the discussion was inconclusive (IIRC)
>>> because of 2 reasons:
>>
>>>   . revno is not unique: two different branches can have the same
>>>     revno for two very different code bases
>>
>> Maybe we should try and provide the revno of the common ancestor on
>> the trunk.
>
> That information only makes sense for mirrors of trunk.
>
> The revision-id is the real info. The fact that it is inconvenient to
> handle is no excuse for doing the wrong thing. And revnos are definitely
> the wrong thing to look at when determining which source code was used
> for a build.


This information below is what is presented in my patched Emacs. Does
that seems enough? (The information is fetched as I described before
in this thread.)

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
This Emacs was built from sources in bazaar identified as:

Nick 'trunk' info:
  revision id: michael.albinus@gmx.de-20100810095815-466r7u9diofu8f0n
        revno: 101040
         date: 2010-08-10 11:58:15 +0200

Nick 'emacsw32' (from 'trunk') info:
  revision id: lennart.borgman@gmail.com-20100810151436-zc9x1d8h6g98edom
        revno: 99334
         date: 2010-08-10 17:14:36 +0200

[back]	[forward]
<<<<<<<<<<<<<<<<<<<<<<

Re: `about-emacs' - what about the revno?

[Stefan Monnier]

>> Maybe we should try and provide the revno of the common ancestor on
>> the trunk.
> That information only makes sense for mirrors of trunk.
> The revision-id is the real info.

The revision-id from a local branch only exists in that local branch, so
it's useless to anybody else than the owner.  I.e. it's not "the real
info" we need.


        Stefan

Re: `about-emacs' - what about the revno?

[Óscar Fuentes]

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

>>> Maybe we should try and provide the revno of the common ancestor on
>>> the trunk.
>> That information only makes sense for mirrors of trunk.
>> The revision-id is the real info.
>
> The revision-id from a local branch only exists in that local branch, so
> it's useless to anybody else than the owner.  I.e. it's not "the real
> info" we need.

So for what we use the revision information? How it helps to know which
was the last commit from trunk included on a build? What's the use case?

AFAIU the info is for knowing the source code used for the build, and
its main usage is for bug reports.

Having the revision-id you can test if the sources comes straight from
Savannah. If it doesn't, the bug is his business, as we have no way of
figuring out what changes his build contains.

A revision-id uniquely identifies the state of a branch, the revision
number does not. For what we need a number that may or may not
correspond to some commit on `trunk'?

Re: `about-emacs' - what about the revno?

[Stefan Monnier]

> So for what we use the revision information? How it helps to know which
> was the last commit from trunk included on a build?

It relates his code to the one in our repository, i.e. to something
about which we know something.

> What's the use case?

When he reports a bug that's supposedly been fixed recently, we can know
whether his report is because he uses an old version that doesn't yet
have the patch applied.  This has already happened a few times over the
last few months.
That's the only use-case I know for a "revision information".

> Having the revision-id you can test if the sources comes straight from
> Savannah. If it doesn't, the bug is his business, as we have no way of
> figuring out what changes his build contains.

Yes, that's also a valid approach.

> A revision-id uniquely identifies the state of a branch, the revision
> number does not. For what we need a number that may or may not
> correspond to some commit on `trunk'?

I never suggested to use just "bzr revno", instead I suggest to use "the
revno on the trunk of the common ancestor".  It also uniquely identifies
a particular revision, and moreover it's a revision which we know.
And being a revno makes it slightly more convenient since you can more
easily (i.e. in your own head) compare two revnos to know whether it
contains a particular patch.


        Stefan