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

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

Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:

> On 4/1/2011 9:21 PM, Óscar Fuentes wrote:
>
>>
>> So you are in favor of using revnos when you know that the revision you
>> are referencing is on trunk, and revids otherwise?
>
> Dear Oscar, In the subthread started by Stephen Turnbull, I have
> argued that it is easy enough to decode revision numbers as long as
> they are referring to the mainline or the local branch.  He has agreed
> with that argument.
>
> Can you comment on whether this convention suits you?

I don't get the part about the local branch. If you branch from trunk
when the tip revno is 10, then commit locally (revno 11) then commit
again locally (revno 12) mentioning your revno 11 on the commit message,
finally merge the changes into trunk which meanwhile advanced to revno
15, this is how trunk looks like afterwards:

16 merge uday's awesome feature into trunk
16.1.2 Fix bug introduced on revision 11
16.1.1 Implement awesome feature
14 someone else's changes
13 someone else's changes
12 someone else's changes
11 someone else's changes
10 someone else's changes
....

So 16.1.2 mentions revision 11, which is wrong.

Other issues with your proposal are:

 1. People do as they see. If you put revnos on trunk's commit messages
    they get the message that it is okay to do that on their branches
    too.

 2. Related to the previous, it is undesirable to add exceptions to
    policies.

 3. If you are inspecting the VC history on a branch and wish to see
    where certain commit with revno X mentioned on a commit message, bug
    report, etc fits on the context of your branch, you must go out of
    your way to look up on trunk the revid of X.

 4. Generalizing the previous point: revids remain valid after a merge,
    revnos don't.