Re: recent changes to org files

[David Kastrup]

Carsten Dominik <address@hidden> writes:

>> To me the rule goes as follows: I only install patches, not files.
>> That usually takes core of those problems: if the author's version
>> disagrees with the CVS version I get a conflict when I try to apply
>> the patch.
>
>
> To me it works like this: My copy is the master copy, not the one in
> Emacs.  The best setup for me would be to get email notifications,
> maybe with a patch, whenever some Emacs developer touches my files
> in Emacs.  Then I can decide if I agree with these changes and
> incorporate the accepted part into my master copy.

But this does not change that any changes by Emacs developers to the
copy in Emacs have been put there in the course of Emacs development
and with the usual amount of peer review for patches.  It is certainly
your choice to accept those patches (or not) into your master copy.
However, that does not mean that this decision should result in
clobbering the changes in the Emacs copy.

It is never correct to do or undo changes in Emacs without Changelog
entry and/or CVS log.  And dissent over the desirability of some
change should not result in "battling commits".

So the right solution can never be just copying over existing files
without any attempt of merging the changes or explaining why they were
undone.

My personal recommendation would be to use the git mirror of Emacs'
CVS.  Using gitk or a number of other git-related tools, it is dead
easy to instantaneously view all changes done in Emacs (git keeps an
impressively well-packed copy of the whole repository with the entire
history locally), merge in your own changes and synchronize stuff.

I think the going rate for the Linux kernel is about 50 patches per
hour that get accepted by Linus Torvalds into upstream, so the
toolchain is rather well-suited to this sort of thing.

-- 
David Kastrup