Comments on: The Balkanization of Distributed Version Control http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/ parsing, performance, minimalism with C99 Mon, 06 Feb 2012 23:44:51 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: beza1e1 http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/comment-page-1/#comment-722 beza1e1 Tue, 14 Aug 2007 08:46:24 +0000 http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/#comment-722 I try to do "some academic research" on this and i'd like to hear your opinion on how to do the evaluation: http://computerroriginaliascience.blogspot.com/2007/08/how-to-evaluate-dvcs.html I try to do “some academic research” on this and i’d like to hear your opinion on how to do the evaluation:

http://computerroriginaliascience.blogspot.com/2007/08/how-to-evaluate-dvcs.html

]]> By: Chris Smith http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/comment-page-1/#comment-708 Chris Smith Thu, 05 Jul 2007 21:56:22 +0000 http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/#comment-708 Funny. You said "What really bothers me about this situation is that this field (dVCS) is not very well understood yet." I was thinking the opposite: I'd be in favor of fewer options if the ideas were well understood. I want more options because the ideas aren't well understood. If there were only one or two products that dominated so much that no one considered using anything else, I'd worry that we might miss some of the good ideas. Funny. You said “What really bothers me about this situation is that this field (dVCS) is not very well understood yet.” I was thinking the opposite: I’d be in favor of fewer options if the ideas were well understood. I want more options because the ideas aren’t well understood. If there were only one or two products that dominated so much that no one considered using anything else, I’d worry that we might miss some of the good ideas.

]]> By: josh http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/comment-page-1/#comment-707 josh Thu, 05 Jul 2007 17:16:32 +0000 http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/#comment-707 Rodrigo: I agree that diversity is good <i>when you have interoperability</i>. I'm not convinced that we have that with dVCS today. Neil: Your point is taken -- for end users, they have to choose a product based on its existing strengths and weaknesses. I think I'm more concerned about people who are acting as advocates and pundits of the dVCS world. I think Jim Gettys is right that "Repository formats matter," but not for the reasons he advances. Luis: what cases does Git optimize for vs. darcs vs. hg? I don't think any of these projects is consciously picking a niche they excel at. Sure, Linus made Git for his very specific use cases, but I haven't seen any analysis of why it is fundamentally any better at this than Mercurial. Bryan: agreed. To me, it's silly for yet another reason: if ftruncate is racy, that's a <b>bug in Linux</b>, not a weakness of Hg. Mike: I can believe that, I just hope that the people who are deciding "what works" will start making comparisons more substantive than to say that one has "more legs." What does that even mean? Rodrigo: I agree that diversity is good when you have interoperability. I’m not convinced that we have that with dVCS today.

Neil: Your point is taken — for end users, they have to choose a product based on its existing strengths and weaknesses. I think I’m more concerned about people who are acting as advocates and pundits of the dVCS world. I think Jim Gettys is right that “Repository formats matter,” but not for the reasons he advances.

Luis: what cases does Git optimize for vs. darcs vs. hg? I don’t think any of these projects is consciously picking a niche they excel at. Sure, Linus made Git for his very specific use cases, but I haven’t seen any analysis of why it is fundamentally any better at this than Mercurial.

Bryan: agreed. To me, it’s silly for yet another reason: if ftruncate is racy, that’s a bug in Linux, not a weakness of Hg.

Mike: I can believe that, I just hope that the people who are deciding “what works” will start making comparisons more substantive than to say that one has “more legs.” What does that even mean?

]]> By: Mike Laiosa http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/comment-page-1/#comment-706 Mike Laiosa Thu, 05 Jul 2007 17:10:57 +0000 http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/#comment-706 I agree with Luis Bruno. The fact that dVCS isn't well understood is exactly why there are many implementations. And its why thats a good thing. Since dVCS isn't well understood, any single implementation probably gets it wrong. The way to gain understanding of dVCS is to try a bunch of things and see what works and what doesn't. Once the space is better understood, someone will write an implementation that gets it right (or people will recognize which of the existing implementations get it right), and the others will go away. I agree with Luis Bruno. The fact that dVCS isn’t well understood is exactly why there are many implementations. And its why thats a good thing. Since dVCS isn’t well understood, any single implementation probably gets it wrong. The way to gain understanding of dVCS is to try a bunch of things and see what works and what doesn’t. Once the space is better understood, someone will write an implementation that gets it right (or people will recognize which of the existing implementations get it right), and the others will go away.

]]> By: Bryan O'Sullivan http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/comment-page-1/#comment-705 Bryan O'Sullivan Thu, 05 Jul 2007 16:13:29 +0000 http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/#comment-705 Jim Gettys's article on repository formats is an annoying pile of nonsense, by the way. It's grown legs because Jim is respected for other work he's done, but that doesn't make what he has to say in that article any less silly. The essence of having a race condition is that you must have two participants, and Mercurial locks a repository that it's modifying so that there can only be *one*. Very simple and difficult to overlook. Jim Gettys’s article on repository formats is an annoying pile of nonsense, by the way. It’s grown legs because Jim is respected for other work he’s done, but that doesn’t make what he has to say in that article any less silly.

The essence of having a race condition is that you must have two participants, and Mercurial locks a repository that it’s modifying so that there can only be *one*. Very simple and difficult to overlook.

]]> By: Luis Bruno http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/comment-page-1/#comment-704 Luis Bruno Thu, 05 Jul 2007 16:04:34 +0000 http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/#comment-704 You've said it yourself: "What really bothers me about this situation is that this field (dVCS) is not very well understood yet." That's why there are so many, each of those a kind-of research in a certain direction. Git optimizes for some cases, darcs for others, hg somewhere else. The Collective doesn't understand this (dVCS) area yet. You’ve said it yourself: “What really bothers me about this situation is that this field (dVCS) is not very well understood yet.”

That’s why there are so many, each of those a kind-of research in a certain direction. Git optimizes for some cases, darcs for others, hg somewhere else. The Collective doesn’t understand this (dVCS) area yet.

]]> By: Neil Bartlett http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/comment-page-1/#comment-703 Neil Bartlett Thu, 05 Jul 2007 14:00:21 +0000 http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/#comment-703 Are you suggesting that (for example) a Windows-only shop should choose Git simply because they prefer a node-centric design, and ignore the fact that there is currently no good implementation of Git for Windows? Comparing these tools based on their philosophical characteristics is all very well, and a good area for academic study... but when it comes down to actually choosing which one to use, it's absolutely vital to look at implementation issues. Are you suggesting that (for example) a Windows-only shop should choose Git simply because they prefer a node-centric design, and ignore the fact that there is currently no good implementation of Git for Windows?

Comparing these tools based on their philosophical characteristics is all very well, and a good area for academic study… but when it comes down to actually choosing which one to use, it’s absolutely vital to look at implementation issues.

]]> By: Rodrigo http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/comment-page-1/#comment-702 Rodrigo Thu, 05 Jul 2007 13:33:36 +0000 http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/#comment-702 It isn't balkanization. It is diversity. And that is a very good thing. But that's just my 2 cents. It isn’t balkanization. It is diversity. And that is a very good thing. But that’s just my 2 cents.

]]> By: Matt Brubeck http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/comment-page-1/#comment-670 Matt Brubeck Tue, 05 Jun 2007 18:38:22 +0000 http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/#comment-670 I've successfully used both SVK and bzr-svn, though not extensively. I certainly wouldn't hesitate to use them. I personally haven't used <a href="http://www.darcs.net/DarcsWiki/Tailor" rel="nofollow">Tailor</a>, but I've been hearing praise for it for quite a while. Mozilla.org successfully <a href="http://weblogs.mozillazine.org/preed/2007/04/version_control_system_shootou_1.html" rel="nofollow">converted their huge CVS repository to Mercurial</a>, though they hit a lot more bugs and limitations along the way than the average project. "That will preserve all metadata about the changes (author, commit messages, timestamps, etc)." That much seems to be easy and widely-supported. I don't know, however, how well any of these tools preserve more complex metadata like branch/merge histories, especially between tools with different concepts of merging. I’ve successfully used both SVK and bzr-svn, though not extensively. I certainly wouldn’t hesitate to use them. I personally haven’t used Tailor, but I’ve been hearing praise for it for quite a while. Mozilla.org successfully converted their huge CVS repository to Mercurial, though they hit a lot more bugs and limitations along the way than the average project.

“That will preserve all metadata about the changes (author, commit messages, timestamps, etc).”

That much seems to be easy and widely-supported. I don’t know, however, how well any of these tools preserve more complex metadata like branch/merge histories, especially between tools with different concepts of merging.

]]> By: josh http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/comment-page-1/#comment-665 josh Mon, 04 Jun 2007 07:19:20 +0000 http://blog.reverberate.org/2007/06/03/the-balkanization-of-distributed-version-control/#comment-665 The thing about tools like this is that they have to be *so good* before they are at all usable. I have to be able to trust that the tool can handle normal cases totally perfectly, and that it will refuse to do anything it can't do perfectly (or let me pass a --force flag). Have you used any tools of this sort that you have that much confidence in? That will let you pull changes from or push changes to a repository in a different format? That will preserve all metadata about the changes (author, commit messages, timestamps, etc). If there is anything like that, it would be good news. Surely these tools have their limits; I want to be sure I know what those limits are. The thing about tools like this is that they have to be *so good* before they are at all usable. I have to be able to trust that the tool can handle normal cases totally perfectly, and that it will refuse to do anything it can’t do perfectly (or let me pass a –force flag).

Have you used any tools of this sort that you have that much confidence in? That will let you pull changes from or push changes to a repository in a different format? That will preserve all metadata about the changes (author, commit messages, timestamps, etc). If there is anything like that, it would be good news.

Surely these tools have their limits; I want to be sure I know what those limits are.

]]>