Re: Emacs on OS X development

[Óscar Fuentes]

Paul Eggert <address@hidden> writes:

> On 07/29/2012 09:48 PM, Óscar Fuentes wrote:
>> using branches for ports would help to determine
>> where the bug was introduced
>
> I don't see why.  In either case, one must look
> at the history.  With branches, the history is less
> complicated to some extent (because one sometimes needs to look
> only at one branch's history) but more complicated in
> other respects (because one must sometimes look at
> another branch's history, if a merge introduces
> a problem);

If a merge introduced a problem into a branch, the merged history
already is in that branch, i.e. no need to look at the other branch.

If a bug is reproducible on the "canonical" or master branch (let's say
that it is the one devoted to GNU/Linux and compatible systems) you
don't need to walk through unrelated, port-specific commits while
searching for suspects. If the bug is known to affect only a given port,
you don't need to isolate the port-specific commits from the rest, as
the DAG will show them nicely. Plus, bisection effort is greatly
reduced.

IMO, the idea of using a branch per port is not something that would
bring in great advantages to Emacs. I think of it as something to
consider. At some point in the past I devoted a slice of time to study
the Emacs C sources and it was a bit of an inconvenience to discriminate
which parts contained the relevant code, among so much obsolete stuff
(quite a bit of that was cleared since) and port-specific code that was
either intermixed with the rest (there are some #ifdef...#endif chunks
that comprise hundreds of lines!) or on files that becomes noise on the
listings. If emacs goes the route of adidng new ports to the core source
base, those annoyances would become worse and worse. I know of projects
that, for every platform they support, the number of relevant files is a
minority within the whole set. Not saying that Emacs will reach that
state anytime soon, but it is something that is better to avoid, if
possible, even while it is a lesser problem.

[snip]