headers
Juanma Barranquero | 1 Apr 2011 01:14
Picon
Gravatar

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

On Thu, Mar 31, 2011 at 22:47, Óscar Fuentes <ofv <at> wanadoo.es> 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.

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

  emacs-23 r100373 is rendered unnecessary by pre-existing 2010-05-20
  trunk change.

  Backport revno:103582 from trunk.

  Fix the MS-Windows build broken by r102878 and emacs-23/r100409.

Seems pretty clear to me.

> 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
(Continue reading)

Permalink | Reply | 41 comments |
headers
Thien-Thi Nguyen | 1 Apr 2011 01:16
Favicon

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

() Óscar Fuentes <ofv <at> wanadoo.es>
() Thu, 31 Mar 2011 22:47:27 +0200

   please use the revision id, which is unique for every commit.

I think it would both more vcs-agnostic and programmer-friendly to use a
date and commit title (presuming the commit has one).  For example:

  2011-03-31  Thien-Thi Nguyen  <ttn <at> gnuvola.org>

  	[lib] Fix bug: Reorder #include "libserveez/foo.h" in libserveez.h.

  	Regression (due to omission) introduced 2011-03-04,
  	"Mark #include "libservez/foo.h" as internal".
  	Lesson: Take care when discarding dependency (ordering) info!

  	* libserveez.h: Move ‘pipe-socket’ and ‘portcfg’ before ‘cfg’.

Here, the date is 2011-03-04, and the title is "Mark ... internal".
These two pieces of info are usually sufficient to uniquely identify a
particular change, and a nice side benefit is that the window of the bug
is apparently computable (in this example almost four weeks -- eep!).

More mumblings on ChangeLog format at:

  http://git.savannah.gnu.org/cgit/serveez.git/tree/HACKING?h=next#n228
Permalink | Reply | 18 comments |
headers
Óscar Fuentes | 1 Apr 2011 02:11
Picon

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

Juanma Barranquero <lekktu <at> gmail.com> writes:

> On Thu, Mar 31, 2011 at 22:47, Óscar Fuentes <ofv <at> wanadoo.es> 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.)
(Continue reading)

Permalink | Reply | 38 comments |
headers
Óscar Fuentes | 1 Apr 2011 02:20
Picon

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

Thien-Thi Nguyen <ttn <at> gnuvola.org> writes:

>    please use the revision id, which is unique for every commit.
>
> I think it would both more vcs-agnostic and programmer-friendly to use a
> date and commit title (presuming the commit has one).  For example:
>
>   2011-03-31  Thien-Thi Nguyen  <ttn <at> gnuvola.org>
>   
>   	[lib] Fix bug: Reorder #include "libserveez/foo.h" in libserveez.h.
>   
>   	Regression (due to omission) introduced 2011-03-04,
>   	"Mark #include "libservez/foo.h" as internal".
>   	Lesson: Take care when discarding dependency (ordering) info!
>   
>   	* libserveez.h: Move ‘pipe-socket’ and ‘portcfg’ before ‘cfg’.
>   
> Here, the date is 2011-03-04, and the title is "Mark ... internal".
> These two pieces of info are usually sufficient to uniquely identify a
> particular change, and a nice side benefit is that the window of the bug
> is apparently computable (in this example almost four weeks -- eep!).

Your proposal is much better than using revision numbers, IMO. It is
actually informative, although it makes difficult to pinpoint the
mentioned revision or to answer the question "is the mentioned revision
on branch X?" which is automatic when you have a revision id.

A different issue is to convince people to write proper commit messages,
with the first line acting as the commit title. But that is another
battle.
(Continue reading)

Permalink | Reply | 17 comments |
headers
Juanma Barranquero | 1 Apr 2011 02:28
Picon
Gravatar

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

On Fri, Apr 1, 2011 at 02:11, Óscar Fuentes <ofv <at> 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.
(Continue reading)

Permalink | Reply | 36 comments |
headers
Stefan Monnier | 1 Apr 2011 02:55
Picon

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

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

Agreed.  In the past we've also used dates as in "fix 2009-10-07
change", which aren't as precise as rev-ids and might prove ambiguous,
but are more stable than rev-nbs and more readable than rev-ids
(especially when reading the ChangeLog where the dates are available).

        Stefan
Permalink | Reply | 0 comments |
headers
Óscar Fuentes | 1 Apr 2011 03:20
Picon

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

Juanma Barranquero <lekktu <at> 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
(Continue reading)

Permalink | Reply | 24 comments |
headers
Stephen J. Turnbull | 1 Apr 2011 03:31
Picon
Favicon

Re: lexbind: how to replace lexical-let approach to hide secrets

Ted Zlatanov writes:

 > IMHO this should be done by Emacs; the core should provide a way to tag
 > strings as "secret" so they are wiped on deallocation.

I don't see why this is better than the method already used, since you
would have to use a different call to make such strings.  In the end
it's up to the application to manage these secrets.

 > I think this property should propagate when the string is copied.

But what about the storage the string is copied from?  Really, keeping
secrets is up to the application.  I think this is overkill, and won't
really help naive users keep their secrets.
Permalink | Reply | 10 comments |
headers
Stephen J. Turnbull | 1 Apr 2011 03:59
Picon
Favicon

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

Juanma Barranquero writes:
 > On Fri, Apr 1, 2011 at 02:11, Óscar Fuentes <ofv <at> 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.

That's only because so far, people don't lose push races often enough
for it to matter.  Commits that from your point of view are on the
mainline really are on local branches until you succeed in pushing.
If you use a bound branch, you're saved from that, true (this is not
entirely trivial, but I'm pretty sure in practice it will be true).
But bound branches suck for anything much bigger than a typo fix.

If you lose a push race, you have to undo the commit so you can redo
the commit message.  That (a) sucks even if you know what you're
doing, and (b) is probably beyond the average Emacs committer at that
moment.  (b) is no insult, just my estimate of a fact, and I see *no
reason* why that should change.  And of course (c) a lot of people
will forget (or never know about it in the first place).  I've been
annoyed by this a couple of times in XEmacs.

 > I don't foresee that super-distributed future that you imagine for
 > Emacs.

It doesn't require a super-distributed future, just an Emacs sprint.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Stephen J. Turnbull | 1 Apr 2011 03:35
Picon
Favicon

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

Juanma Barranquero writes:

 > > 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"?

Sure.  But then everything is.  "Sometimes Emacs crashes, so don't use
Emacs."  It is very typical to refer to a parent revision in a feature
branch.  I don't see why one should stop doing so.
Permalink | Reply | 1 comment |

Gmane