0

I wonder why there is no Mercurial plugin to work with Launchpad/Bazaar from Mercurial? Is there any technical limitation that make it impossible to use local Mercurial storage/clone for working with remote Bazaar repositories?

3
  • You mean a bazaar (bzr) plug-in, and because nobody has written one, presumably. Feel free to do so.
    – dobey
    Jan 25, 2015 at 14:08
  • @dobey, clarified the question. Jan 25, 2015 at 14:36
  • Narrowed the question scope. Please review. Jan 27, 2015 at 13:53

1 Answer 1

1

The reverse (bzr-hg) did exist, but that plugin has been abandoned in 2012. See https://launchpad.net/bzr-hg. I suspect a hg-bzr plugin didn't emerge for similar reasons as why we gave up on the bzr-hg plugin, in addition to the fact that the popularity of bzr has simply waned - so a plugin is less necessary.

One of the problems with the bzr-hg plugin was that both Bazaar and Mercurial have lower-level APIs that are (were) changing often enough that the plugin would regularly break.

Bazaar and Mercurial also have quite a different data model - the difference is bigger than between e.g. Bazaar and Git - which made it hard to convert revisions in a performant manner.

Mercurial and Bazaar have a number of features that are hard to map between them.

  • The information in Mercurial manifests and Bazaar inventories can't be converted back and forth easily - you need lookup tables for file identification information
  • Bazaar revision properties are similar to Mercurial extras, but they don't support special characters (or the other way around)
  • Mercurial doesn't support "ghost revisions", revisions that are referenced but not present in the repository
  • Mercurial doesn't have a concept of file ids, so file ids need to be stored elsewhere in the repository like a special file
  • Mercurial doesn't support empty directories, multiple commit authors or revisions with more than two parents ("octopus merges", in Git terminology)

These things are a lot easier when interacting with Git, because it is content-addressable and simpler (e.g. it doesn't have per-file revision graphs). Hg-Git or Bzr-Git can just import whatever you have in Git into Mercurial and so long as you end up converting it back into Git with the same representation, you get the same commit SHA as you had originally.

3
  • Some of these points look like implementation details, but quite a different data model point is more interesting. Of those, converting ghost revisions, empty directories and multiple authors will result in data loss. Is that all or there are more conceptual differences? (I don't know Bazaar data model) Feb 6, 2015 at 13:04
  • There are also file ids, revision ids that are a part of the data model in Bazaar. Note that these don't necessarily mean data loss - you could store them elsewhere in mercurial, e.g. in extras, or a magic file. But that does significantly complicate the implementation.
    – jelmer
    Feb 6, 2015 at 22:08
  • It looks like providing additional data to prevent data loss is a common pattern. I even saw people used it for video compression. There only problem is a common anchor point. Feb 7, 2015 at 12:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .