Re: org changes lost

[Stefan Monnier <monnier@iro.umontreal.ca>]

> My skills in version control my not be sufficient to do this, jumping
> between different version control worlds.

You just need to reflect the branch of one into a branch of the other
(one-way only), so it's not that difficult.  E.g. you can commit (via
naive overwrite&commit) your externally-maintaned code into a special
branch in the CVS, and then use cvs to merge the changes from that
branch into the trunk.

Or you can do it the other way around and take a copy of Emacs's trunk
every once in a while, commit it onto a special branch in your main
VCS (e.g. Bzr or Git), and then merge that branch into your main branch.

The safer thing to do (when working between VCS or without VCS) is to
never copy files, but only ever take diffs and apply them.  It's not
like taking diffs is safer but it forces you to think "diff between what
and what", so it makes it more likely that you'll do the right thing.

> So I work by applying changed in Emacs to my local copy and reserve the
> right to undo changes made in Emacs (not that this has been necessary
> recently).  Usually this works OK, occasionally, like yesterday,
> I miss something.

To avoid this, try to do a "diff since last sync" and apply that to
Emacs's repository.  This may result in conflicts, but only if there are
concurrent changes that you need to pay attention to.

> For me the biggest improvement would be to get an email copy
> of all changes to files where I am the maintainer, not buried
> in the general commits digest (where I do overlook things),
> but a personalized one. I am sure that such emails could be
> generated automatically, but I don't know how.

That would be good indeed.  Maybe someone could setup such a service:
register to emacs-diffs, and then use a table that maps file names to
maintainers's email addresses to figure out to whom to send the email.
The table can be rebuilt daily by looking at the Elisp files's
"Maintainer:" or "Author:" line and the admin/MAINTAINERS (which is
a bit out-of-date, AFAIK).  This data tends to be out-of-date, tho, so
while this doesn't mean it's a bad idea, it means your email filter
should be careful to handle such things gracefully (whatever that
means, my guess is that it'll just work without having to do anything
special, other than add a little blurb to the email to explain how to
"unsubscribe").


        Stefan