Re: Please don't use revision numbers on commit messages (and elsewhere).

[Óscar Fuentes]

Juanma Barranquero <address@hidden> writes:

> On Thu, Mar 31, 2011 at 22:47, Óscar Fuentes <address@hidden> wrote:
>
>> A revision number only makes sense on the branch where it was created
>> (and this only after setting some options, as Emacs did.)
>
> Yeah, well, we're dealing with Emacs, not some random bzr branch.

The Emacs project has a number of branches published on a well-known
site, and hopefully other branches distributed along a number of
personal machines. I'm saying that using revision numbers is confusing
when those revisions are merged across branches. Across *any* branches,
including the "random" ones (whatever your definition of "random branch"
is.)

>> If I'm reading
>> the VC log on a random branch and see "Fix breakage introduced by rXXXX"
>> and want to look at the referenced revision, I need to switch to trunk
>> and hope that XXXX corresponds to one of its revisions.
>
> Revision numbers refering to the trunk seem to be, until now, the most
> common case.

Maybe this is because `trunk' is where almost all the work is done and
used as a centralized repo where the hackers commit as they progress
(instead of using long-lived feature branches.) That is subject to
change over time as people gets acquainted with distributed features
(or, hopefully, as new hackers join the project.)

> And I see that people sometimes uses the branch name as
> an adjetive to clarify which one contains the revno:
>
>   Merge from emacs-23 branch, up to r100386.

[snip]

> Seems pretty clear to me.

This is not terribly helpful, as it forces you to clone a number of
branches just for reference and jump from one to another, when the
mentioned revision may be already merged in your current
branch. (Usually I'm interested on seeing the revision in the context of
my current work, so I'll have to clone and switch to the other branch,
lookup the revision-id there, and use it on my branch for locating the
revision.)

>> If a series of
>> commits on a feature branch mentions one another by revison number,
>> after merging them into trunk (or into any other branch) those numbers
>> are wrong.
>
> Isn't that a case of "if it hurts, don't do that"?

So we need another rule: if you are working on a branch other than
`trunk', use revision ids, else revision numbers. Creppy.

>> So, if you wish to refer to another revision on the commit message (or
>> anywhere else) please use the revision id, which is unique for every
>> commit.
>
> It's also quite unwieldy. git SHA-1 ids seem a joy by comparison (at
> least you can use a prefix of 6-8 characters and be right most of the
> time).

Yes, bzr's revision ids sucks, but that is no reason for doing the wrong
thing.

Just in case anyone here has the time and energy, it could be suggested
to bzr hackers to implement a SHA-1 revision id in parallel of the
currrent monster. Sequential numbering is just wrong on a distributed
VCS.