[Top][All Lists]
[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
- Switching to bzr: what Emacs developers should know?, Bastien, 2009/08/08
- bzr for Gnus (was: Switching to bzr: what Emacs developers should know?), Ted Zlatanov, 2009/08/11
- bzr for Gnus (was: Switching to bzr: what Emacs developers should know?), Stephen J. Turnbull, 2009/08/12
- Re: bzr for Gnus (was: Switching to bzr: what Emacs developers should know?), Mike Kupfer, 2009/08/12
- Re: bzr for Gnus, Ted Zlatanov, 2009/08/12
- Re: bzr for Gnus, Miles Bader, 2009/08/12
- Re: bzr for Gnus, Stefan Monnier, 2009/08/13
Re: Switching to bzr: what Emacs developers should know?, Bastien, 2009/08/08
Re: Switching to bzr: what Emacs developers should know?, Bastien, 2009/08/08