Re: MAINTAINERS file

[Jason Earl]

Thien-Thi Nguyen <address@hidden> writes:

> () Jason Earl <address@hidden>
> () Wed, 05 Mar 2008 16:07:38 -0700
>
>    In this particular case "pretty close" means
>    [importing was in progress].
>
> Thanks for the clarification.

My pleasure.

>    [Importing is slow.]  I then used my spare time in the next
>    several weeks playing around with some of the other available
>    methods for migrating from CVS (or git) to bzr.
>
> This is something all programmers migrating to bzr from CVS (or
> git) will have to do.  So, ...

Yes, but they only have to do it once per project, and most projects
have far less to convert than Emacs.

>    [...] I really debated speaking up about my experiments,
>    because for the most part they have shown that bzr's import
>    tools aren't quite up to the task of converting Emacs.  I have,
>    however, made enough progress that I would almost certainly
>    would be helpful to anyone that was interested in experimenting
>    with bzr for themselves.
>
> ..., i suggest you set up a public bzr repo of that tool, w/ a nice
> fat warning in the README.  This will help people to: play w/ bzr
> directly; use it to flush out problems w/ the import process; and use
> it to flush out problems w/ Emacs' bzr (and other dVCS) support.  Two
> (plus) birds w/ one stone.

That's the idea.  Once the initial conversion is complete keeping the
bzr repo in sync with the official Emacs CVS repo should be fairly
straightforward.

> (Of course, there is the risk that one of the birds to be struck will
> be people's patience w/ multi-level breakage.  That flighty thing, yet
> hard of wing... :--)

I happen to like bzr.  I've played around with all of the major (and
most of the minor) revision control systems and I believe that bzr
strikes a nice balance between usability and functionality.  It is easy
to deploy (no smart server required), it's commands are familiar to
people that have used cvs and it supports a wide variety of workflows
including a CVS/subversion style workflow with "bound" branches.  It
installs easily anywhere that Python 2.4 runs, and it has a large and
talented group of hackers working on it.  I would like to see Emacs move
in that direction.

On the other hand, I don't think that Emacs could go wrong with either
git (assuming that a workable Windows client could be found) or
Mercurial, and I have already successfully created a Mercurial Emacs
repository from the existing git repository.  To be honest, as much as I
like bzr, Mercurial is hard to beat.

Jason