emacs-devel
[Top][All Lists]
Advanced

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

Re: MAINTAINERS file


From: Jason Earl
Subject: Re: MAINTAINERS file
Date: 2008年3月06日 12:09:29 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Thien-Thi Nguyen <address@hidden> writes:
> () Jason Earl <address@hidden>
> () 2008年3月05日 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

reply via email to

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

AltStyle によって変換されたページ (->オリジナル) /