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

["Óscar Fuentes" <ofv@wanadoo.es>]

Juanma Barranquero <lekktu@gmail.com> writes:

[snip]

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

Anyone can setup a public repo anytime, anywhere. Let's think of a
long-lived feature branch of the type of lexbind or bidi which, for
whatever reason, the participating developers finds more convenient to
host outside of Savannah. Unless he remembers to set the appropriate
options on the public repo's config, it will be subjected to the same
line revision renumbering that happened to Emacs' trunk on the
past. Recommending to use revision ids instead of revision numbers would
help to avoid the problem.

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

In the case of patches, using revision ids on the commit messages is,
actually, most convenient, because on that case the referenced ids are
unambiguous no matter on which branch the patch is applied.

> The Emacs project does not usually maintain a large number of active
> branches.

On a distributed project, you don't know how many active branches exist
out there.

> And, with a shared repo, "cloning a number of branches"
> isn't that problematic, space- or time-wise.

Let me expand with an example based on my past* experience. I have a
number of heterogeneous machines (different OS, varying network
connectivity, etc) and on all of them I have Emacs running (of
course!). I've my private branch with some customizations, which is what
I use for building and installing Emacs on all those machines. Keeping
the private branch mirrored among all of them means work. Keeping
mirrors for `trunk', emacs-23 and what-not is too much of a burden (last
time I checked there was no simple & reliable method for synchronizing
sets of branches across multiple platforms.) In theory, having just my
private branch and merging trunk into it from time to time would be
enough. But then those commits messages referencing other revisions by
their numbers doesn't fit, as trunk's revision #110000 has another
number on my private branch.

(*) "That other DVCS" handled the described scenario perfectly.

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

Do you prefer to wait until the problem has manifested itself on all its
crudeness? :-)

[snip]