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

[Juanma Barranquero <lekktu@gmail.com>]

On Fri, Apr 1, 2011 at 02:11, Óscar Fuentes <ofv@wanadoo.es> wrote:

> 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.

Yes, and I'm saying that, so far, it seems quite clear from the
context which branch a revno refers to.

> Across *any* branches,
> including the "random" ones (whatever your definition of "random branch"
> is.)

My comment about "random branches" is an answer to your "(and this
only after setting some options, as Emacs did.)".

We're developing Emacs; it's irrelevant whether other projects do or
do not set these options.

> 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.)

I don't foresee that super-distributed future that you imagine for
Emacs. And if it does come to pass, it's everyone's responsibility to
clearly label their revnos.

After all, if you have a branch cloned from trunk, and you do
development on it, and you do refer to revids in the changelogs, these
revids won't be meaningful for the trunk's users either unless the
branch is merged to the trunk. If you just send a patch, revids will
be as meaningless as revnos would be.

> 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.

The Emacs project does not usually maintain a large number of active
branches. And, with a shared repo, "cloning a number of branches"
isn't that problematic, space- or time-wise.

> (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.)

It's hard to envision you cloning emacs-23 to locate a revision, then
removing it from the disk, then cloning it again to locate the next
revision...

Also, that example is currently quite artificial, because they aren't
that many revnos in the ChangeLogs right now (I know, I checked the
logs) and they overwhelming refer to the trunk. So you're describing a
future, hypothetical problem.

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

No. Use always revision numbers and trust the users to be smart.

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

Neither it is an incentive to do the "right thing".

    Juanma