{"thread":{"id":"5964","subject":"Re: VCS comparison table","startedAt":"2006-10-20T13:22:20Z","lastAt":"2006-10-20T16:24:25Z","messageCount":8,"participants":["Horst H. von Brand","Christian MICHON","Jakub Narebski","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"29345","messageId":"200610201322.k9KDMKk0011370@laptop13.inf.utfsm.cl","threadId":"5964","inReplyTo":"aaron.bentley@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-10-20T13:22:20Z","receivedAt":"2006-10-20T13:22:20Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Aaron Bentley <aaron.bentley@utoronto.ca> wrote:\n> Linus Torvalds wrote:\n\n[...]\n\n> > The \"main trunk matters\" mentality (which has deep roots in CVS - don't \n> > get me wrong, I don't think you're the first one to do this) is \n> > fundamentally antithetical to truly distributed system, because it \n> > basically assumes that some maintainer is \"more important\" than others. \n\n> Linus, if you got hit by a bus, it would still be a shock, and it would\n> still take time for the Linux world to recover.  Your insights and\n> talent, both technical and social, make you the most important kernel\n> developer.  And it stays that way because you deserve it.  Projects with\n> good leadership don't fork, or if they do, the fork withers and dies\n> pretty quickly.\n\nSo? It makes no sense to me to cater only to \"successful projects\"... most\nprojects /aren't/ successful ;-)\n\n> It is fine to say all branches are equal from a technical perspective.\n> From a social perspective, it's just not true.\n\nYes, but what matters here is the principle... if branches aren't equal, it\nmakes some things unnecessarily hard (i.e., forking, passing maintainership\nover, ...). Sure, they aren't activities that should be actively\nencouraged, but they shouldn't be made harder than necessary either.\n\n> The scale of Bazaar development is much smaller than the scale of kernel\n> development, so it doesn't make sense to maintain long-term divergent\n> branches like the mm tree.  We do occasionally have long-lived feature\n> branches, though.\n\nAre you saying Bazaar is aimed at small(ish) projects (only)?\n\n> > That special maintainer is the maintainer whose merge-trunk is followed, \n> > and whose revision numbers don't change when they are merged back.\n\n> In bzr development, it's very rare for anyone's revision numbers to\n> change.\n\n\"Very rare\" != \"never\". The \"very rare\" cases /will/ come back to bite you,\nonce you grow accustomed to \"hasn't ever happened\"\n\n[...]\n\n> > I'll just point out that one of my design goals for git was to make every \n> > single repository 100% equal. That means that there MUST NOT be a \"trunk\", \n> > or a special line of development. There is no \"vendor branch\".\n\n> I think you're implying that on a technical level, bzr doesn't support\n> this.  But it does.  Every published repository\n\nWhat makes a \"published repository\" special, as oposed to my local\nplayground?\n\n>                                                 has unique identifiers\n> for every revision on its mainline,\n\nAre they different among repositories, even though they came from another\nof the set?\n\n>                                     and it's exceedingly uncommon for\n> these to change.\n\nSee above.\n\n>                   There are special procedures to maintain bzr.dev, but\n> there's nothing technically unique about it.  People develop against\n> bzr.dev rather than my integration branch, because they have\n> non-technical reasons for wanting their changes to be merged into\n> bzr.dev, not my integration branch.\n\nOK.\n"},{"id":"29351","messageId":"46d6db660610200646r502d01d5kb84cc218c24e42ce@mail.gmail.com","threadId":"5964","inReplyTo":"200610201322.k9KDMKk0011370@laptop13.inf.utfsm.cl","subject":"Re: VCS comparison table","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2006-10-20T13:46:49Z","receivedAt":"2006-10-20T13:46:49Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 10/20/06, Horst H. von Brand <vonbrand@inf.utfsm.cl> wrote:\n> Are you saying Bazaar is aimed at small(ish) projects (only)?\n\nfunny. I actually read another post from Linus, and when I\n\"merge\" with your post (understand: bisect), the following\ncomes out:\n\n- git is the fastest scm around\n- git has the smallest scm footprint\n- git is also aimed at small(ish) projects\n\nmy personal proof of concept on the last point is that I'm a\nIC design engineer who threw away other scm in favor of git\nsince git-1.4.2 and regret now the years wasted on _other_\nscm. But your mileage may vary.\n\n-- \nChristian\n"},{"id":"29369","messageId":"ehaojp$2qv$2@sea.gmane.org","threadId":"5964","inReplyTo":"46d6db660610200646r502d01d5kb84cc218c24e42ce@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T15:05:35Z","receivedAt":"2006-10-20T15:05:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Christian MICHON wrote:\n\n> - git is the fastest scm around\n\nMercurial also claims that. It probably depends on the benchmark, though.\nBut Mercurial (hg) lacks from what I understand persistent branches, and\nhas only partial support for renames. YMMV.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29370","messageId":"Pine.LNX.4.63.0610201715040.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5964","inReplyTo":"ehaojp$2qv$2@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-20T15:16:25Z","receivedAt":"2006-10-20T15:16:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 20 Oct 2006, Jakub Narebski wrote:\n\n> Christian MICHON wrote:\n> \n> > - git is the fastest scm around\n> \n> Mercurial also claims that.\n\nFunny. When you type in \"mercurial\" and \"benchmark\" into Google, the \n_first_ hit is into \"git Archives: Mercurial 0.4b vs git patchbomb \nbenchmark\". Performed by the good Mercurial people.\n\nLeaving git as winner.\n\nCiao,\nDscho\n"},{"id":"29371","messageId":"200610201728.13327.jnareb@gmail.com","threadId":"5964","inReplyTo":"Pine.LNX.4.63.0610201715040.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T15:28:13Z","receivedAt":"2006-10-20T15:28:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> On Fri, 20 Oct 2006, Jakub Narebski wrote:\n> \n>> Christian MICHON wrote:\n>> \n>>> - git is the fastest scm around\n>> \n>> Mercurial also claims that.\n> \n> Funny. When you type in \"mercurial\" and \"benchmark\" into Google, the \n> _first_ hit is into \"git Archives: Mercurial 0.4b vs git patchbomb \n> benchmark\". Performed by the good Mercurial people.\n> \n> Leaving git as winner.\n \nCheck out http://git.or.cz/gitwiki/GitBenchmarks section \"Quilt import \ncomparison of Git and Mercurial\" for the latest (OLS2006) benchmark\nby Mercurial. Probably not indexed by Google, or doesn't have high \npagerank because it is in PDF and fairly new (therefore has low \n\"citations\" number).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29377","messageId":"Pine.LNX.4.63.0610201736440.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5964","inReplyTo":"200610201728.13327.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-20T15:39:19Z","receivedAt":"2006-10-20T15:39:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 20 Oct 2006, Jakub Narebski wrote:\n\n> Johannes Schindelin wrote:\n> \n> > On Fri, 20 Oct 2006, Jakub Narebski wrote:\n> > \n> >> Christian MICHON wrote:\n> >> \n> >>> - git is the fastest scm around\n> >> \n> >> Mercurial also claims that.\n> > \n> > Funny. When you type in \"mercurial\" and \"benchmark\" into Google, the \n> > _first_ hit is into \"git Archives: Mercurial 0.4b vs git patchbomb \n> > benchmark\". Performed by the good Mercurial people.\n> > \n> > Leaving git as winner.\n>  \n> Check out http://git.or.cz/gitwiki/GitBenchmarks section \"Quilt import \n> comparison of Git and Mercurial\" for the latest (OLS2006) benchmark\n> by Mercurial.\n\nThanks for the hint!\n\nBTW the tests in Clone/status/pull make sense, especially the \"4 times \nslower on pull/merge\". In my tests, merge-recur (the default merge \nstrategy, which was written in Python, and is now in C) was substantially \nfaster.\n\n> Probably not indexed by Google, or doesn't have high pagerank because it \n> is in PDF and fairly new (therefore has low \"citations\" number).\n\nI hope these posts boost the pagerank.\n\nCiao,\nDscho\n"},{"id":"29382","messageId":"200610201805.40235.jnareb@gmail.com","threadId":"5964","inReplyTo":"Pine.LNX.4.63.0610201736440.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T16:05:39Z","receivedAt":"2006-10-20T16:05:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n> On Fri, 20 Oct 2006, Jakub Narebski wrote:\n>> Johannes Schindelin wrote:\n>>> On Fri, 20 Oct 2006, Jakub Narebski wrote:\n>>> \n>>>> Christian MICHON wrote:\n>>>> \n>>>>> - git is the fastest scm around\n>>>> \n>>>> Mercurial also claims that.\n>>> \n>>> Funny. When you type in \"mercurial\" and \"benchmark\" into Google, the \n>>> _first_ hit is into \"git Archives: Mercurial 0.4b vs git patchbomb \n>>> benchmark\". Performed by the good Mercurial people.\n>>> \n>>> Leaving git as winner.\n>>  \n>> Check out http://git.or.cz/gitwiki/GitBenchmarks section \"Quilt import \n>> comparison of Git and Mercurial\" for the latest (OLS2006) benchmark\n>> by Mercurial.\n> \n> Thanks for the hint!\n> \n> BTW the tests in Clone/status/pull make sense, especially the \"4 times \n> slower on pull/merge\". In my tests, merge-recur (the default merge \n> strategy, which was written in Python, and is now in C) was substantially \n> faster.\n\nAs it was mentioned somewhere else in this thread, to compare times\nfor pull/merge in git with other SCM one should in principle substract\ntime for diffstat/git diff --stat.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29386","messageId":"ehat7i$mua$1@sea.gmane.org","threadId":"5964","inReplyTo":"200610201805.40235.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T16:24:25Z","receivedAt":"2006-10-20T16:24:25Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n> Johannes Schindelin wrote:\n>> On Fri, 20 Oct 2006, Jakub Narebski wrote:\n>>> Johannes Schindelin wrote:\n>>>> On Fri, 20 Oct 2006, Jakub Narebski wrote:\n>>>> \n>>>>> Christian MICHON wrote:\n>>>>> \n>>>>>> - git is the fastest scm around\n>>>>> \n>>>>> Mercurial also claims that.\n>>>> \n>>>> Funny. When you type in \"mercurial\" and \"benchmark\" into Google, the \n>>>> _first_ hit is into \"git Archives: Mercurial 0.4b vs git patchbomb \n>>>> benchmark\". Performed by the good Mercurial people.\n>>>> \n>>>> Leaving git as winner.\n>>>  \n>>> Check out http://git.or.cz/gitwiki/GitBenchmarks section \"Quilt import \n>>> comparison of Git and Mercurial\" for the latest (OLS2006) benchmark\n>>> by Mercurial.\n>> \n>> Thanks for the hint!\n>> \n>> BTW the tests in Clone/status/pull make sense, especially the \"4 times \n>> slower on pull/merge\". In my tests, merge-recur (the default merge \n>> strategy, which was written in Python, and is now in C) was substantially \n>> faster.\n> \n> As it was mentioned somewhere else in this thread, to compare times\n> for pull/merge in git with other SCM one should in principle substract\n> time for diffstat/git diff --stat.\n\nOr as reminded, use -n, --no-summary option to git pull.\n\nBTW. I'd rather have -n == --no-commit for git pull...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}