emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Óscar Fuentes
Subject: Re: Please don't use revision numbers on commit messages (and elsewhere).
Date: Fri, 01 Apr 2011 17:55:23 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Juanma Barranquero <address@hidden> writes:

> On Fri, Apr 1, 2011 at 03:20, Óscar Fuentes <address@hidden> wrote:
>
>> 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.
>
> I think Eli has already answered that: if/when it happens, we can
> discuss how to minimize the problems. Until now, it is entirely
> hypothetical.

See my response to Eli about this.

>> 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.
>
> "Unambiguous" does not mean "I have it accessible and I know which
> branch it refers to". Are you defending using revids because they are
> unique, or because you don't like to having around multiple branches?

Both reasons. Please note that if I read a reference to revision #XXXX
on a commit message (or bug report...) and want to see its log on my
machine, the scenario is at least as bad as if we were using revision
ids.

>> On a distributed project, you don't know how many active branches exist
>> out there.
>
> Last time I checked, Emacs wasn't a "distributed project". It is a
> centralized project with a distributed tool that helps developers.

Once Emacs switched to a dVCS, it is a distributed project. You can
insist on its centralization all the time, but the truth is that working
on Emacs on a distributed way is a decisions that now belongs to each
and every hacker. I can have my private branches, I can publish them
from my machine, I can exchange revisions with other hackers. Eventually
I can contribute those changes to "central" Emacs, but the process was
distributed all the way, because I chose to do so. Whatever informal
policy some Emacs hackers follow, it is irrelevant to me.

> Sorry, you lost me here. "trunk, emacs-23 and what-not" can be mostly
> summarized to "trunk, emacs-23 and nothing else", *unless* you're
> actively tracking window-pub, lexbind-new or some other branch, which
> most people (even developers) apparently don't do. If we maintained
> dozens of branches, all of them vibrant with activity, I could buy it.
> But we use a development branch and a release branch, and a few
> almost-private-development-branches-that-nobody-tracks, and that
> doesn't seem likely to change in the near future.

This looks like defeatism :-)

>> Do you prefer to wait until the problem has manifested itself on all its
>> crudeness? :-)
>
> Sure I do. And you know why? Because Bazaar revnos are *convenient*,
> and Bazaar revids are a royal PITA. I don't want to abandon convenient
> shorthands for what, at the moment, is just FUD.

Maybe you perceive the issue as FUD because your workflow?

I admit that the problem is negligible *now*. How much importance it
will adquire on the future depends on how Emacs development evolves. You
say it will not turn serious because Emacs development will not
change. Okay, time will tell.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]