Comments on: Linus Torvalds explains distributed source control http://kylecordes.com/2007/05/17/linux-git-distributed/ Kyle Cordes's Software Site Sat, 06 Mar 2010 00:56:20 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Mark http://kylecordes.com/2007/05/17/linux-git-distributed/comment-page-1/#comment-8894 Mark Wed, 06 Jun 2007 08:07:57 +0000 http://kylecordes.com/2007/05/17/linux-git-distributed/#comment-8894 Bzr ("bazaar") is the revision control system we chose for the Ubuntu project, because of its perfect support for renames. By "perfect" I mean that you cannot break Bzr no matter how aggressively your community renames files and directories. One contributor can rename a directory, someone else can rename a subdirectory, and other people can rename files *and add* files in both directories, and then you can merge from all of them, and It Just Works. Bzr was designed for multiplatform work, so it has the best support for Windows too (not a big issue for Ubuntu, but definitely an issue for upstreams). Early versions of Bzr were slower than Git or Mercurial, but the performance is improving constantly, and Bzr now takes less than a second ("heartbeat time") to do a status on a project of up to 5,000 files. I think the team is confident they will match Mercurial in performance without losing their advantages on renaming robustness. Commit is still slower on Bzr, but status is the key performance item from a usability perspective. So, please add Bzr to your list of things people shoudl check out. bazaar-vcs.org. Bzr (“bazaar”) is the revision control system we chose for the Ubuntu project, because of its perfect support for renames. By “perfect” I mean that you cannot break Bzr no matter how aggressively your community renames files and directories. One contributor can rename a directory, someone else can rename a subdirectory, and other people can rename files *and add* files in both directories, and then you can merge from all of them, and It Just Works.

Bzr was designed for multiplatform work, so it has the best support for Windows too (not a big issue for Ubuntu, but definitely an issue for upstreams).

Early versions of Bzr were slower than Git or Mercurial, but the performance is improving constantly, and Bzr now takes less than a second (“heartbeat time”) to do a status on a project of up to 5,000 files. I think the team is confident they will match Mercurial in performance without losing their advantages on renaming robustness. Commit is still slower on Bzr, but status is the key performance item from a usability perspective.

So, please add Bzr to your list of things people shoudl check out. bazaar-vcs.org.

]]> By: Alec the Geek http://kylecordes.com/2007/05/17/linux-git-distributed/comment-page-1/#comment-7995 Alec the Geek Sun, 03 Jun 2007 20:18:46 +0000 http://kylecordes.com/2007/05/17/linux-git-distributed/#comment-7995 <strong>Linux Poster Boy Talks about SCM...</strong> Códice Software: Linus Torvalds on GIT and SCM speech Linus Torvalds gave some days ago at Google, basically talking about GIT and Source Control Management Codice Software have a nice blog entry about Linus’ presentation on Source Control Mana... Linux Poster Boy Talks about SCM…

Códice Software: Linus Torvalds on GIT and SCM
speech Linus Torvalds gave some days ago at Google, basically talking about GIT and Source Control Management
Codice Software have a nice blog entry about Linus’ presentation on Source Control Mana…

]]> By: Nathan Neff http://kylecordes.com/2007/05/17/linux-git-distributed/comment-page-1/#comment-6696 Nathan Neff Wed, 23 May 2007 18:22:28 +0000 http://kylecordes.com/2007/05/17/linux-git-distributed/#comment-6696 I've been checking out darcs, which is also a distributed source control tool, and it was easy to set up and work with. I had a bit of a problem with the overzealous default filter (it didn't import .class files, and I wasn't able to get it to allow .class files). There was talk of it being slow. I tested darcs on a smaller "project", it works fine for smaller projects. Has anyone else experimented with darcs? I’ve been checking out darcs, which is also a distributed source control tool, and it was easy to set up and work with.

I had a bit of a problem with the overzealous default filter (it didn’t import .class files, and I wasn’t able to get it to allow .class files). There was talk of it being slow. I tested darcs on a smaller “project”, it works fine for smaller projects.

Has anyone else experimented with darcs?

]]> By: Alex Miller http://kylecordes.com/2007/05/17/linux-git-distributed/comment-page-1/#comment-6658 Alex Miller Sun, 20 May 2007 03:18:38 +0000 http://kylecordes.com/2007/05/17/linux-git-distributed/#comment-6658 Also, I should mention that you will find links in Mark's post to an evaluation that was done prior for Open Solaris, where Mercurial was chosen over bzr and git. Also, I should mention that you will find links in Mark’s post to an evaluation that was done prior for Open Solaris, where Mercurial was chosen over bzr and git.

]]> By: Alex Miller http://kylecordes.com/2007/05/17/linux-git-distributed/comment-page-1/#comment-6657 Alex Miller Sun, 20 May 2007 03:14:25 +0000 http://kylecordes.com/2007/05/17/linux-git-distributed/#comment-6657 This is an interesting topic and I don't think you should miss the ruminations that have been going on in the Java world in the process of open-sourcing the JDK. Several key people have been blogging on the selection and conversion process for moving from Sun's internal TeamWare system to <a href="http://www.selenic.com/mercurial/wiki/" rel="nofollow">Mercurial</a> (a distributed SCM). Most recently, check out: <a href="http://blogs.sun.com/mr/entry/openjdk_scm" rel="nofollow">Mark Reinhold's</a> recent entry and also the blogs from <a href="http://weblogs.java.net/blog/kellyohair/archive/2006/09/teamware_and_me.html" rel="nofollow">Kelly O'Hair</a> and <a href="http://weblogs.java.net/blog/martin/archive/2006/09/migrating_from_1.html" rel="nofollow">Martin Englund</a>. Certainly, there has been some outcry from the Java public about not choosing Subversion but apparently Sun did not feel that it met the basic requirements. So, I would suspect that Mercurial (which I can't type for anything...arrghg) is going to be receiving a lot of attention in the near future. Maybe another one to consider. The blogs linked above contain a bunch more interesting links, The authors have other blog entries on these topics as well. This is an interesting topic and I don’t think you should miss the ruminations that have been going on in the Java world in the process of open-sourcing the JDK. Several key people have been blogging on the selection and conversion process for moving from Sun’s internal TeamWare system to Mercurial (a distributed SCM). Most recently, check out: Mark Reinhold’s recent entry and also the blogs from Kelly O’Hair and Martin Englund. Certainly, there has been some outcry from the Java public about not choosing Subversion but apparently Sun did not feel that it met the basic requirements. So, I would suspect that Mercurial (which I can’t type for anything…arrghg) is going to be receiving a lot of attention in the near future. Maybe another one to consider. The blogs linked above contain a bunch more interesting links, The authors have other blog entries on these topics as well.

]]> By: Todd Jordan http://kylecordes.com/2007/05/17/linux-git-distributed/comment-page-1/#comment-6656 Todd Jordan Sun, 20 May 2007 03:04:32 +0000 http://kylecordes.com/2007/05/17/linux-git-distributed/#comment-6656 Best quote: <em>There are important differences between source control tools. I have heard it said that these are all “just tools” which don’t matter, you simply use whatever the local management felt like buying. That is wrong: making better tool choices will make your project better (cheaper, faster, more fun, etc.), making worse tool choices will make your project worse (more expensive, slower, painful, higher turnover, etc.)</em> The inertia of our current shops will carry us even past the newness and best practices being found today, until they are replaced by even better tools. Many shops won't know the joy of tools like Git until it's old news. But I see hope against this inertia as the 'old skoolrz' age out and move up, and the next generation want to experiment more. Thanks for the excellent and well thought out post. Best quote:
There are important differences between source control tools. I have heard it said that these are all “just tools” which don’t matter, you simply use whatever the local management felt like buying. That is wrong: making better tool choices will make your project better (cheaper, faster, more fun, etc.), making worse tool choices will make your project worse (more expensive, slower, painful, higher turnover, etc.)

The inertia of our current shops will carry us even past the newness and best practices being found today, until they are replaced by even better tools. Many shops won’t know the joy of tools like Git until it’s old news.

But I see hope against this inertia as the ‘old skoolrz’ age out and move up, and the next generation want to experiment more.
Thanks for the excellent and well thought out post.

]]> By: Kyle Cordes http://kylecordes.com/2007/05/17/linux-git-distributed/comment-page-1/#comment-6649 Kyle Cordes Sat, 19 May 2007 16:48:00 +0000 http://kylecordes.com/2007/05/17/linux-git-distributed/#comment-6649 I don't have a recommendation, though I expect to have one eventually, after we have substantial experience on real projects. SVK appears to be the most closely suited at being used as a better SVN client, though of course it's much more than that. I have personally tested cloning an SVN project then committed changes back, with git and SVK. I am using bzr for another project, and it supports that kind of using with an svn plugin, but I haven't tried that plugin yet. I don’t have a recommendation, though I expect to have one eventually, after we have substantial experience on real projects.

SVK appears to be the most closely suited at being used as a better SVN client, though of course it’s much more than that. I have personally tested cloning an SVN project then committed changes back, with git and SVK. I am using bzr for another project, and it supports that kind of using with an svn plugin, but I haven’t tried that plugin yet.

]]> By: Craig Buchek http://kylecordes.com/2007/05/17/linux-git-distributed/comment-page-1/#comment-6647 Craig Buchek Sat, 19 May 2007 16:33:15 +0000 http://kylecordes.com/2007/05/17/linux-git-distributed/#comment-6647 I'm looking to move from Subversion to SVK or Bazaar (bzr) myself. Do you have any advice on which one to choose? I want to keep my Subversion mainline repositories on the web, but do offline development on my notebook. I’m looking to move from Subversion to SVK or Bazaar (bzr) myself. Do you have any advice on which one to choose? I want to keep my Subversion mainline repositories on the web, but do offline development on my notebook.

]]> By: Brian Gilstrap http://kylecordes.com/2007/05/17/linux-git-distributed/comment-page-1/#comment-6628 Brian Gilstrap Thu, 17 May 2007 15:16:07 +0000 http://kylecordes.com/2007/05/17/linux-git-distributed/#comment-6628 I look forward to viewing the talk. But I also <a href="http://viewfromthefringe.blogspot.com/2007/05/kyle-cordes-on-tools.html" rel="nofollow">really like<a> your statement about tools not being 'just tools'. I look forward to viewing the talk. But I also really like your statement about tools not being ‘just tools’.

]]> By: Dan Miser http://kylecordes.com/2007/05/17/linux-git-distributed/comment-page-1/#comment-6624 Dan Miser Thu, 17 May 2007 15:10:54 +0000 http://kylecordes.com/2007/05/17/linux-git-distributed/#comment-6624 Thanks for that very complete post (and link), Kyle. You are always finding a way to push the envelope! :-) Thanks for that very complete post (and link), Kyle. You are always finding a way to push the envelope! :-)

]]>