Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 02 Aug 2012 14:28:43 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: "Stephen J. Turnbull" <stephen@xemacs.org>, dmantipov@yandex.ru, 
>  monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
> 
> 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.