Its quite clear from the various discussions related to DVCS that there isn’t going to be one clear winner for the choice of VCS for Gnome; everyone wants to use their favourite DVCS. So here’s an idea, why not allow them to?
I think that the deciding factor for which DVCS to use is the quality of the tools that enable interoperability between all the other possible tools. Obviously there is tailor which automates migration of patchsets between different DVCS’s, but I want more native support within the tool I’m using; i.e if I’m using git I want to use “git’s terminology” to “pull and push” from the remote repository. I’ve found git-bzr for interoperating between git and bzr, and similarily there is bzr-git for the other way around, although I’ve not yet had time to see how either of the tools work.
Basically I think that the decision of which DVCS to choose should be based upon which DVCS is the easiest to import into all the others(or at least just the most popular ones!). This makes all the other points regarding speed etc really quite moot so long as these tools work well (In particular I’d like to observe how well they maintain merge histories between the DVCS systems – maybe when I get time in the next few weeks I’ll do some experimenting).
This is a really, really bad idea.
blah: Why respond if you don’t have any arguments?
Regarding suggestion: I’d wish that suggestion was possible. But, I don’t think git-bzr will be as seamless as what e.g. Bzr-git would be able to provide. Just choosing Git on the server on that basis is IMO mad, given that I’d likely have to support it (while I don’t get it). Further, the likely method of Bzr would probably to call git commands directly, which IMO isn’t a nice integration method, plus you still have interoperability problems (Windows).
Also think of the information stored, and size and such (which matters for the server).
meike: I don’t think that information stored is that much of an issue with DVCS, I don’t think I’ve ever come across a situation where the DVCS repository is bigger (and in most cases it is an order of magnitude smaller) than the svn repository from which it was converted.
[...] James Sharpe doesn’t think a choice needs to be made if the systems interoperate; [...]
You haven’t actually used Tailor, have you? Done any converting of code between VCSs? It’s always incomplete, buggy, and leaves garbage behind.
You might want to try it before suggesting it. I think you’ll see pretty quickly why it’s a bad idea!
If you’re talking about just “skinning” the git engine with bzr commands, that doesn’t work either. They’re very different under the hood; at best, you’ll create a mess of leaky abstractions and another baffling porceleain that nobody uses.
You haven’t actually used Tailor, have you? Done any converting of code between VCSs? It’s always incomplete, buggy, and leaves garbage behind.
You might want to try it before suggesting it. I think you’ll see pretty quickly why it’s a bad idea!
If you’re talking about just “skinning” the git engine with bzr commands, that doesn’t work either. They’re very different under the hood; at best, you’ll create a mess of leaky abstractions and another baffling porceleain that nobody uses.