emacs-devel
[Top][All Lists]
Advanced

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

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIEL


From: Eli Zaretskii
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames.
Date: Fri, 03 Aug 2012 09:27:46 +0300

> Date: Thu, 02 Aug 2012 14:28:43 -0700
> From: Paul Eggert <address@hidden>
> CC: "Stephen J. Turnbull" <address@hidden>, address@hidden, 
>  address@hidden, address@hidden
> 
> On 08/02/2012 08:45 AM, Eli Zaretskii wrote:
> > the same is
> > probably true for GC-related work: it mainly affects alloc.c
> 
> I'm afraid not.  Dmitry is right: GC affects lots of files,
> basically, anything that touches a data structure that might
> be garbage-collected.
> 
> My experience with merging is closer to Dmitry's, I'm afraid.
> It's no fun merging, say, the FVAR/WVAR/etc patches with the
> inline-function patches that I have pending for post-24.2
> <http://bugs.gnu.org/11935>.

Mega changes such as FVAR/WVAR/etc should be treated as outliers in
this statistics.  (One more reason to avoid them if at all possible,
btw.)

> It's not that it can't be done -- of course it can -- but it's
> tedious and error-prone.  The FVAR/etc patches and the inline
> patches are both pervasive, and so have many opportunities
> to collide with each other.

Again, let's not build card towers from a single extreme case.

Anyway, I gave numbers for my experience.  It would be good to see
yours, or someone else's.  It's all there in your ~/.bzr.log file, so
just grep it and tell how many conflicts you had in your merges, and
not just for the last FVAR/etc incident.



reply via email to

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