Missing git and/or hg (Mercurial) support

Please see https://answers.edge.launchpad.net/launchpad-bazaar/+faq/37. (Closing this ticket with status "won't fix").

Looks more like a "bazaar is from canonical and launchpad will only support THAT because we want to push it". Well, I hope it will start to support other (D)VCS if LP will go open source this year and other people will develop some extensions. :-)

Or maybe RedMine or Trac is a better idea.

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...)

Yes, I read the FAQ item. But thanks for your details. You really should add this text a little bit modified to the FAQ.

Anyway, than LP isn't a primary host of a project that won't use bazarr natively? If my project uses Mercurial I will need another repository that LP will "import" as bzr+hg?

i read the faq which gives a reason, but does not explain it. i read your statement above, karl, and it does not mention a single issue you would have with mercurial or git. both are used as clients for other version control systems without loosing any information.

and there is another problem: one wants to host a project with launchpad, and use his favoured version control tool, which is in 98% of the cases *not* bazaar. one does *not* care about import possibilities.

@SoloTurn:

Well, for a concrete example: Mercurial does not (and will not) version directories as first class objects. Bazaar does. Therefore, Bazaar can represent an empty directory's appearance in history, while Mercurial cannot. Whether most projects need this ability or not is not the point -- the point is that Mercurial cannot represent a history that Bazaar can, yet the reverse is not true. (Well, at least for this case. I don't know of any case where Mercurial can represent a history that Bazaar cannot, but I haven't personally studied that question in enough detail to claim it with certainty. However, I think it is more likely true than not; counterexamples welcome.)

Something similar is true about first-class renames, w.r.t. both Mercurial and Git, I believe.

So AFAIK, you *can* actually lose some information if you use Git or Mercurial as a client against a Bazaar repository. (Again, I'm making these claims based on shallow research, and welcome opinions more expert than mine.)

@André Klitzing:

Yes, you've got it right. And I've linked to this discussion from the FAQ item now.

Karl Fogel wrote:
> (Well, at least for this case. I
> don't know of any case where Mercurial can represent a history that
> Bazaar cannot, but I haven't personally studied that question in enough
> detail to claim it with certainty. However, I think it is more likely
> true than not; counterexamples welcome.)

File copies?

By the way, bzr-git cannot import the Git project's history (IIRC; could
be a different major project) because some early files used complex
permissions, but Bazaar can only represent 0644 and 0755.
--

just to clarify: bzr-git can import the git projects' history fine, but can't store those odd permissions anywhere yet.

I don't see what's "silly" about continuous import from a Launchpad-hosted Mercurial/Git repository; it's a simple, easy-to-implement solution that seems to address the needs of people who can't or don't want to switch to Bazaar.

@karl - why do you want to force a project to track directories, if it is happy to not do it? sourceforge, redhat, and may others support multiple version control systems, and different users/project like different version control systems. launchpad does not deserve beeing handicapped by bazaar's deficiencies.

I'd like to strongly encourage you as well to add native support for at least git and Mercurial into LP.

I must admit that despite the fact that I really like bazaar the fact that LP development is clutching so vehemently to bzr has a strange taste to it - there are enough other good features in bzr to convice developers. Applying the force of bundling has never been a good concept to make OSS developers use a specific solution.

I for myself would like to bundle my coding activities using self-hosted LP but currently this is cumbersome because as a contract worker I have to use git as well as my customers want me to. There are probably a significant number of other devs facing a similar situation.

So please rethink your decision. It strongly harms deployment popularity of LP just for the dubious cause of pushing bzr.

Good morning everybody.

I'm was/am using cvs, tla, monotone, svn, git, hg, bzr, darcs for some time and see a lot of discussions about launchpad, lighthouse, github, gitorious, freshmeat, sourceforge,... asking which platform to use for which version control system.

In my opinion you can establish yourself with either of the two strategies:

- support no VCS at all (=freshmeat), be neutral
- try to support all VCS (no one does that (yet?))

It's no question whether bzr can collect everything from any other VCS: The question is, can platform X support
MY VCS DIRECTLY or not?

If you support only one VCS, you will fail exactly at the same time this VCS failed.

If you somehow provide support for (almost) all of the popular VCS (which today includes at least svn, hg, darcs and git) you can succeed.

This can even be done by some smart filters you put in front of bzr (like git cvsserver), so people do not
notice that you are using bzr as the backend.

But forcing people (this includes no direct support for my preferred VCS) to use one method will sooner or later make people use a different platform (*).

Thus I'm pretty much wondering, which strategy you'll drive and if you survive.

Nico

(*): This is *not* true for simple VCS hosting like gitorious, which is a dumb backend, which is only designed to be a filekeeper.

Personally, I wouldn't mind using bzr, except the lack of mature IDE plugins makes it difficult to switch (specifically, for eclipse). Now, I know plugins do exist, but I would not consider them mature and usable.

kfogel: Actually the nice "Bazaar for Git users" tutorial (http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html#design-differences) quite nicely lists, why git users won't give up on this tool and switch to bzr. People don't only love git for being distributed, they even more love git exactly for the design differences listed in that document. They are what enabled this stellar adoption of git.

Also I really wonder why Canonical doesn't wants to fight for the money GitHub and BitBucket are getting from git users. After all Launchpad also is thought as some kind of revenue stream for Canonical, not?

@hasselmm: Well, I haven't worked at Canonical for a while now so I can't say what business plans they might have for Launchpad (though I hope there are some, since it's a great tool). Thanks for the link to that doc -- it's good that someone took the time to write up the issues to that level of detail.

FWIW, I'm a happy user of both git and bzr right now, on different projects. Others' mileage may vary :-).

@kfogel: Sure I am not trying to convince anyone to switch to git. Just pointing out missed opportunity by not fully supporting git.

I'd love to use launchpad in my company, but we use git and we won't switch to Bazaar, so this prevents me from pushing launchpad as a solution for my team :(

It would be great launchpad support git interface.
I'm using git-bzr plugin.

git is a powerfull CVS . FreeBSD now have git repository, the linux kernel, postgresql does it also.

why not canonical close you eyes ?

did you still open to the world?

bzr is not a stable and fast CVS.

see the latest release , it released several month ago.

do you really good enough , and do not need any maintance release?

I can see if you did not open your eyes, you will lost in the future.

github , bitbucket will beat your ass.

At least Microsoft recognized that Git has won: http://techcrunch.com/2013/01/30/microsoft-announces-git-support-for-visual-studio-team-foundation-server-and-service

Canonical might still need some time...

Is this still "won't fix"? We use GIT for a large project (dozens of repositories) and there is no way we will switch to BZR (ever) but we would like to use other features of Launchpad such as translation management.

Thanks!

Timothy: We are indeed working on native Git support now, although rather than reopening this bug we might as well continue to track it in bug 1032731. I can't give you an ETA quite yet, and it will take a while to build it up from basic hosting support to full feature parity with Bazaar in Launchpad, but we want it to happen soon.

Very glad to hear this!