emacs-devel
[Top][All Lists]
Advanced

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

Re: Switching to bzr: what Emacs developers should know?


From: Stefan Monnier
Subject: Re: Switching to bzr: what Emacs developers should know?
Date: Thu, 13 Aug 2009 12:21:42 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

> I've been doing a bit of testing, and bzr can definitely facilitate this
> sort of thing.  In fact, you can set up a test by simply branching from
> an Emacs bzr repository and then using bzr mv and friends to put
> everything where Gnus expects it to be.  bzr will then happily keep
> things up to date even though the files are in different locations.

Yes.  But this still has 2 problems:

- as you noted, this loses Gnus's CVS history.  Maybe there's a way to
  fix it, or do something at least sufficient (e.g. keep the history
  in a completely separate branch).  All that's really needed to "do
  it right" would be for the CVS->Bzr conversion to be able to take
  "file->id" tables from one branch and apply it to the other.

- The above will happily deal with one way synchronization (i.e. future
  commits to the Emacs branch will be easy to merge into the Gnus
  branch), but I still don't know how to do the other sync (merge
  changes made on the Gnus branch onto the Emacs branch).

I've asked a similar question on the Bzr list and was mostly greeted
with silence.  I find it odd: such parallel branches are a pretty common
occurrence, in my experience, so while I understand that it might not be
easy/trivial to handle it, I'd expect at least some interest in trying
to come up with ways to support it.  Maybe there's a way to do it in
Bzr, but I haven't found it yet.  Note that most other VCS are just as
poor at it.  Arch is a bit better (mostly because you can
straightforwardly fiddle with the merge-history), and DaRCS is
positively good at it.

>> This same problem appears with several other packages that are
>> maintained outside Emacs, tho Gnus is the only one to currently
>> benefit from a really nice solution.  So a good solution to this
>> problem would be useful for more than just Gnus.
> For packages maintained outside of Emacs that don't currently have a
> solution to this problem bzr is likely to be a huge step in the right
> direction.  With the right plugin you might even be able to keep using
> git (or hg) for your own hacking and then use bzr to merge with Emacs.

I have no doubt that Bzr will make such things easier than CVS.
The two-way thingy done with Arch for Gnus is just a special treat that
requires extra manual fiddling.  Big thanks to Miles for that.


        Stefan




reply via email to

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