all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Jason Earl <jearl@notengoamigos.org>
Cc: Bastien <bastienguerry@googlemail.com>,
	Karl Fogel <karl.fogel@canonical.com>,
	B Smith-Mannschott <bsmith.occs@gmail.com>,
	emacs-devel@gnu.org
Subject: Re: Switching to bzr: what Emacs developers should know?
Date: Thu, 13 Aug 2009 12:21:42 -0400	[thread overview]
Message-ID: <jwv63cr4rsi.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87fxbyb3s5.fsf@notengoamigos.org> (Jason Earl's message of "Tue,  11 Aug 2009 12:31:54 -0600")

> 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




  parent reply	other threads:[~2009-08-13 16:21 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-08 16:24 Switching to bzr: what Emacs developers should know? Bastien
2009-08-08 18:51 ` B Smith-Mannschott
2009-08-08 19:54   ` Stefan Monnier
2009-08-08 22:41     ` Bastien
2009-08-09  1:23       ` Stefan Monnier
2009-08-11  5:42         ` Karl Fogel
2009-08-11  5:49     ` Karl Fogel
2009-08-11 17:17       ` Stefan Monnier
     [not found]         ` <87fxbyb3s5.fsf@notengoamigos.org>
2009-08-13 16:21           ` Stefan Monnier [this message]
2009-08-11 18:56       ` bzr for Gnus (was: Switching to bzr: what Emacs developers should know?) Ted Zlatanov
2009-08-12  5:28         ` Stephen J. Turnbull
2009-08-12 13:50           ` Mike Kupfer
2009-08-12 15:09             ` bzr for Gnus Ted Zlatanov
2009-09-08 16:27               ` Karl Fogel
2009-09-09  3:11                 ` Stefan Monnier
2009-08-12  8:01         ` Miles Bader
2009-08-13 16:38           ` Stefan Monnier
2009-08-08 22:40   ` Switching to bzr: what Emacs developers should know? Bastien
2009-08-09  0:03   ` Bastien
2009-08-09  2:24     ` Óscar Fuentes
2009-08-18  9:31       ` Bastien
2009-08-09 12:42   ` CHENG Gao
2009-08-11  5:44     ` Karl Fogel
     [not found]       ` <8763cua0za.fsf@notengoamigos.org>
2009-08-11 15:19         ` Karl Fogel
     [not found]           ` <87ocqmb587.fsf@notengoamigos.org>
2009-08-11 18:20             ` Karl Fogel
     [not found]               ` <87bpmmb27v.fsf@notengoamigos.org>
2009-08-11 19:15                 ` Karl Fogel
2009-08-12  5:50               ` CHENG Gao
2009-08-13 16:31               ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv63cr4rsi.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=bastienguerry@googlemail.com \
    --cc=bsmith.occs@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=jearl@notengoamigos.org \
    --cc=karl.fogel@canonical.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.