Comment 3 for bug 292557

No, it's actually not a "Not Invented Here" problem -- the choice really was made on technical grounds. If Bazaar had been written entirely outside Canonical, and we had to choose a native version control system for Launchpad, we'd still choose Bazaar.

Did you read that FAQ item? I edited it to explain this in more detail -- see the part about how Bazaar's data model is flexible enough to represent the semantics of the data imported from other version control systems. That's very important for Launchpad, which has to track upstream projects accurately. (Our bug tracker is in a similar situation: represent the semantics of other bug trackers accurately enough to track upstream bugs.)

If Launchpad were to start supporting other version control systems natively, it would essentially have to do continuous imports from *itself* in order to represent the data accurately to other Launchpad users, for whom Bazaar is not only a version control tool but also an interchange format. We decided that would be silly :-). The current continuous import solution accomplishes nearly the same thing, while also guaranteeing that once the data is in Launchpad, it is in a representation that all the rest of Launchpad (and tools that work with Launchpad, because remember we have APIs to support) knows how to work with. That's means N amount of work and complexity to support N version control systems, instead of N*N.

I hope this makes it clearer.

(Hmm, I wonder if some reworded version of this should go into that FAQ item...)