Linus Torvalds on GIT and SCM
I just finished watching the speech Linus Torvalds gave some days ago at Google, basically talking about GIT and Source Control Management.
He has really strong opinions but I think the video is really worth watching.
To be honest I was very shocked by some of the statements he made, like the following:
Does he really look like an agressive salesguy or is it just me? :-?
BTW there are very important topics to highlight in his presentation, many of them I totally agree with:
(Reviewed on 2009: I'd include TFS here too...)
Branching helps with parallel development, helps making experiments, helps commiting often, helps creating checkpoints, helps keeping the project stable, basically helps working better. I agree with Linus here because branching, and specially merging (check the point where he tells branching is not the problem, but merging: branch with SVN is ok, even with CVS, but then try to handle merging and the nightmare shows up) are the key concepts around which Plastic SCM has been built BTW I'm aware that he would also blame Plastic as he did with SVN, Perforce and all the others but reality is that Plastic is pretty good at merging, and this is one of our core differences with almost any other SCM.
(Reviewed: As you all probably know already, Plastic is really strong on distributed development, specially since we released GUI support for replication on 2.7. I truly believe distributed development is the way to go since:
And what we offer in Plastic (something GIT enforces too since github is out) is the ability to run both centralized or distributed scenarios: every Plastic server can replicate to another, it doesn't matter whether it's running on your laptop or at a corporate server.)
During the last months we have had the opportunity to talk to several companies around the world, and we found that most of the developers are pretty afraid (or confused at least) about branching and merging.
The reason? Well, CVS and SVN can't handle merge history (update SVN 1.5 has introduced merge tracking, but used to be pretty weak), so if you do a merge from a branch and try to repeat it later on after making more changes, you have to solve the full merge again...
This renders merging totally unusable in practice for SVN users (CVS is even worse), and due to its huge spread it has really altered the perception of many developers out there (and I'm just repeating Linus words... ;-P).
Watch the full video here:
Is it planned for Plastic to become open source any time in the future?
ReplyDeleteThis is a pretty interesting question... In fact there has been a lot of debate about this topic internally during the last months...
ReplyDeleteWell, moving to OSS is quite tempting, but I guess the problem is more on the business side.
Creating Plastic required a big investment so before moving to OSS all the pros and cons should be evaluated, and what is more important, Codice should adapt itself to a new business model.
Counting on a community would certainly help creating a bigger user base, getting more feedback, adapting to changes faster...
I'm afraid is not a very clear answer but... I don't have a better one yet...
For the guys without flash in their browser, here a DivX version of the video:
ReplyDeleteTech Talk: Linus Torvalds on git.avi
It's also smaller in size (110MB) than the original FLV from youtube (170MB).
It's a really sad state of affairs that CVS became the lowest common denominator for version control. SVN promised so much but has so far failed to deliver. This coupled with a seemingly lack of SCM education on the part of what appears to be the vast majority of engineers tends to have a negative affect on development processes and practices.
ReplyDeleteHistorically serious corporate development have used ClearCase. But now I'm hearing a lot of people bemoaning the high cost of ClearCase and IBM's high cost of support.
This is worrying as there is then a tendency to go back to CVS-like systems.
I think subversion has succeeded in a lot it set out to do, and as a developer who works on open source projects not as large as the linux kernel, I am happy that svn came along to replace CVS as the defacto standard. I host my projects on google code, and while it might be nice for them to offer better scm systems, for the projects I'm working on I'm just happy not to be using CVS.
ReplyDeleteSVN is more popular because it doesn't offer any radical changes from SVN that would detract from its adoption, and for them to provide some of the features that Linus asks for it would mean alienating CVS users which is counter to the goals of SVN.
Yes, I agree CVS and SVN are the common denominator for many developers out there.
ReplyDeleteIn fact many people simply hate branching because of the horrible merging problems created by SourceSafe, CVS and sometimes also by SVN.
As Linus points, the big deal is not doing branching, but doing good merging.
IMHO the problem is that one of the most strong alternatives, clearcase, is both too expensive and difficult to use and administer.
That's why we basically created Plastic: our main goal is helping small and medium companies adopting better SCM practices with a system that is usable, powerful and introduces new cool features like branch inheritance, ACL security and BTW the graphics...
Very Good website, even I run a similar software website and if you are looing forward for some partnership please email me at r.prathik@gmail.com
ReplyDeleteFrom KingP
http://mysoftwares.freehostia.com
Although it has its own problems (memory usage, speed, implementation language), SVK has solved the merging problem for me. It can use Subversion as the storage medium (and the bulk of the revision tracking), but adds its own layer of features. It uses SVN properties to note merge points to keep track of which revisions have already been merged. In fact, I can use SVK to work with someone else's SVN repo without interfering with other developer's ability to do work. SVK also creates a local repo that lets me work in a separate branch against 3rd-party sources (think vendor branches) so I can track my changes against theirs and not require commit access to the source repo.
ReplyDeleteI branch and merge like a mofo now!
Subversion does *not* require that you remerge all changes in branches. Instead, what you do it remember the last time you merged (i.e. current revision number at time of merge), and then you just merge the changes since the last merge.
ReplyDeleteUnfortunately, Subversion doesn't provide this functionality as a standard, built-in feature, so you have to implement it on top of svn - see my svnmerge and svnbranch scripts for the (super-simple) shell script way...
"For the guys without flash in their browser, here a DivX version of the video:
ReplyDeleteTech Talk: Linus Torvalds on git.avi
It's also smaller in size (110MB) than the original FLV from youtube (170MB)."
And what about a transcript for those of us on dial-up? (28.8Kbps here - best connection available)
This trend of posting all information as video is getting ridiculous. I'm with the ISPs on this one.
I'm sure the text of the presentation would be a tiny fraction of the size of the video. Text, it is a revolutionary way to communicate. A picture is NOT worth a thousand words.
Linus is an idiot.
ReplyDeleteIt IS EASY to make branches in cvs:
cvs rtag my_branch_origin module
cvs rtag -b -r my_branch_origin mybranch module
Done.
Seriously, his assertion that it's "difficult" to make branches in CVS is just a lie, or else he's a moron. And we know he' not a moron.
The issues with centralization are, for the most part, on target. But the assertion that it's difficult to make and merge branches is just retarded.
Likewise, merging is pretty easy:
cvs rtag my_branch merge_todays_date
cvs update -j my_branch_origin -j my_branch_todays_date
cvs commit.
What's so freakin' hard about that?
The whole "I'm right and anyone who disagrees is stupid and ugly" shtick is funny the first time he says it, but as the talk went on, it became pretty clear that it's not an act and that he really is an arrogant prick. It was all the more insulting since half of the SVN dev team was in the audience.
ReplyDeleteFor Linus to come in and tell Google (or any US company) that they should ditch Perforce/ClearCase/SVN/whatever for git is ridiculous and betrays his total ignorance of the conditions these businesses face: SOX compliance alone would be a colossal pain in the ass -- if not impossible -- with git.
git may be "perfect" for the chaotic development model around the Linux kernel, but it's hardly the be-all/end-all of SCM Linus claims it is.
Having used cvs, svn and now clearcase, i would have to comment that problem is actually the management of code development rather than the tool. Unless you have a somewhat disciplined routine of working in parallel and committing/merging, the whole thing gets way out of hand and no tool will help you get it back in order.
ReplyDeleteClearcase imho, has also the misfeature of 'views' which allow multiple versions of viewing the file tree. I think this adds another layer of complexity and confusion to what already is a messy process. I prefer the older tools which have the minimum set of features needed to perform and no more.
The next release of SVN includes merge tracking.
ReplyDeleteWhat is so terrible about SVN merging and branching to begin with? I've never had a problem with it.
What is wrong with branching and merging on SVN? Well, have you ever tried to merge a branch, continue working on it and then try to merge again?
ReplyDeleteHave you ever tried to follow a branch per task pattern?
Try the following: create two branches, in one of them rename a file, in the other one modify it, then merge back to the trunk.... Oh! Oh!
Yes, you will end up with two nice files instead of one...
I never heard of Plastic before but it seems it is almost as good as Accurev and cheaper!!!!
Check this
I prefer the older tools which have the minimum set of features needed to perform and no more.
ReplyDeleteYeah! I also prefered working in plain assembly...
Come on guy!! Evolve or die!
I have used AccuRev in the past, and it handles some of these things pretty well. For example, it always shows you - graphically - what versions a particular file version came from. Maybe Linus should give that a look for some ideas. It isn't perfect, it has some odd quirks (like any system), but it has some good ideas too.
ReplyDeleteSeriously, this guy have no respect for other peoples work and doesn't even take the time to argue for it. Did he actually answer ONE question asked? I felt he just sidestepped anything got thrown at him and then he just pulled up another out of the blue scenario where GIT was better. No he's just arrogant, stupid and ugly. I was able to withstand him for 38 minutes, after that I couldn't handle it anymore.
ReplyDeleteOne guy said above about branching with CVS
ReplyDeleteWhat's so freakin' hard about that?
Are you crazy?? This is not difficult, but compare to any decent SCM...
And the hard thing is not creating the branch, is merging it with a piece of crap like CVS or SVN!!!
please justify the statement that merging is terrible in perforce. in fact, merging is one of its strongest features.
ReplyDeleteGuys, there is no point in arguing over this video.
ReplyDeleteClearly, Linus Torvalds is an arrogant asshole who thinks his opinions matter more than anyone else's.
Not worth the time. Just because he wrote a smallish fraction of the Linux kernel, this doesn't entitle him to be a 'BDFL'. And 'Linux' is a stupid name.
Now, Torvalds if you ever read this,
know that the Linux kernel is a horrible piece of shit with no innovation in it whatsoever. Tanebaum was right, you heard me asshole.
But now I'm hearing a lot of people bemoaning the high cost of ClearCase and IBM's high cost of support.
ReplyDeleteClearCase has always been expensive to purchase and support. What's worth bemoaning is having to deal with IBM, and their "we've got the place surrounded" attitude toward their customers. I've made my living as a ClearCase implementor/administrator for the last 12 years, but only since Rational got bought by IBM have I considered changing careers.
Merging in ClearCase or CVS is so awful that even a quite bad solution is good in comparison. Then again, ClearCase manages to make most other simple things absurdly complex and error-prone too.
ReplyDeleteLinus is good at raising the hackles of the OSS community. Most of us just don't care anymore. Let him use whatever he wants to drive the kernel; I will use whatever is suitable for my projects. To hear him drone on and on like some tool about his "latest favorite SCM" is pointless. To hear him insult other projects because they aren't his own is pretty much just the zen of Linus.
ReplyDeleteIt's possible to do branch and merge with CVS, but it's not all that pleasant. I do it with three tags: a premerge and postmerge tag on the branch and a merge point on the parent (typically the mainline, but it doesn't have to be). As long as one's disciplined about the use of tags, it can be done -- but it's unnecessarily painful and it is error-prone.
ReplyDeleteAbout the Anonymous idiot who wrote "Linus is an idiot."
ReplyDeleteObviously you are retarded beyond recuperation or has never used CVS or SVN with any reasonable sized project (in terms of coders and size)...
Having used both, and also Bitkeeper and Darcs, i agree 100% with Linus. MERGING IS A FREAKING UNBELIAVABLY TIME CONSUMING process both in cvs and in svn...
Bitkeeper is so much better at it, no comparison at all.
Developing separatedly from the main line of development in cvs or svn is just asking for losing your precious time...
Well, CVS nor SVN handle merge history, so if you do a merge from a branch and try to repeat it later on after making more changes, you have to solve the full merge again...
ReplyDeleteThis is not true for CVS. There is a very simple method to handle this. Each time you merge your branch to the head (for example), you tag the branch (bugFix_branch_to_head is a good name). The next time you need to move do a merge, you do cvs update -j bugFix_branch_to_head -j HEAD. This will only merge the changes since the last merge and you don't have to solve the whole think again.
You can either move the tag to the new merge point or make a new one depending on how you choose to work.
I manage the CVS trees and branches and this works very well.
The problem with CVS is that too many people THINK they know how to use it.
I've been using perforce to maintain my own private FreeBSD branch off the mainline for the past 6 and a half years now. I've merged my changes from my private branch into the base FreeBSD tree enough times to remain in the top 10 kernel committers for that entire time. I work on about 5 or 6 different branches at the same time (some are private to me, others are collaborative with others).
ReplyDeleteTo say that perforce doesn't support branching is utter BS, and demonstrates a fundamental ignorance of the tools.
It is rather telling that when FreeBSD did its x.org changes for its ports system with git, that nobody, not even the folks that setup the x.org, could figure out how to get git to do the changes.
Others have suggested that tags in CVS is the way to solve the branching problems. Put simply, tags do not work. The cannot work. How can you tag something that's on the branch, that's then merged back to head and modified by someone else and then merged back to the branch. You get a guaranteed conflict when that happens. Scale this to a project the size of FreeBSD with its thousands of files and hundreds of developers and CVS shows that it can't cope.
Perforce rocks. If people don't think it supports multiple branching, and multiple integration from many places, including 'circular' merges, they don't know what they are talking about. I've been doing that for about 6 and a half years now.
Warner Losh
FreeBSD developer
FreeBSD PC Card maintainer
FreeBSD CardBus Maintainer
FreeBSD Atmel AT91RM92000 Maintainer
FreeBSD PCI/NewBus/USB sometimes contributor.
I've been using perforce to maintain my own private FreeBSD branch for about 5 1/2 years now. I've in the top 5 for FreeBSD kernel committers during that time and perforce makes it sane. I currently work on 5 or 6 different perforce branches depending on what I'm doing. It blows away CVS, it is not even funny.
ReplyDeleteOther contributors suggest that tags are the way to go with CVS. This does help, but still gives you such a low level of functionality, I stopped using that technique in the FreeBSD repository about 6 years ago as totally unworkable.
I find it telling that when FreeBSD cut over to x.org 7.2 recently, the work to make 7.2 work on FreeBSD was done in a git branch. The telling part was that no body could figure out how to do the back integration into the main line, including the folks that setup the x.org git repo.
Linus basically displays his total ignorance of SCM with his over-devotion to git. If people didn't over-diefy him, then this story wouldn't have had any play.
Perforce totally rocks. Its only downside is that it isn't free software.
Warner Losh
FreeBSD CardBus Maintiner
FreeBSD SD/MMC Maintainer
FreeBSD PC Card Maintainer
FreeBSD SPI Maintianer
FreeBSD Atmel AT91RM9200 Maintainer
FreeBSD general infrastructure contributor.
I don't like the fact that your software is only available for Windows and Linux.
ReplyDeleteWhat about OpenSolaris?
We are currently testing the software under Linux and Windows.
ReplyDeleteServer and command line clients run on Solaris (we do test on Solaris 10 SPARC regularly) and Mac too, but they are not included in the test chain yet.
I tried Plastic on Nexenta a couple of times too.
Having used CVS, SVN and Perforce merging *IS* painful in all 3 systems. Merging is easy when there are not conflicts with just about every system. When there are conflicts they become painful. Peforce would be the worst...whats with the submit, resolve crap? The gui tools for seeing conflicts are cool...but I would prefer not to see them at all!
ReplyDeleteGood gods, people, learn a little.
ReplyDelete"Linux is a stupid name". Blame Ari Lemmke, who came up with it. Linus's original name was different, but everyone liked "Linux" better, so he went along with it.
Linus is not known for being shy about his opinions. He's sometimes wrong, but he's right often enough that he's worth listening to. And certainly he's entitled to express his opinion of other SCMs while explaining the design decisions that went into making his.
Might I point out that he's been merge-meister of one of the most active software development projects in the world for fifteen years? Whatever his opinion might be on how to manage large-scale software development, one thing it's not is uninformed.
As for merging in CVS... yes, you can do in 5 steps what a decent SCM can do in two (the need to tag your branch points is very annoying, but fairly mechanical), but that's only the TRIVIAL case. Let's take a more realistic problem:
* Developer A starts work on branch_A.
* There's more hacking on the trunk.
* Developer B starts work on branch_B.
* B needs some bug fixes that A has implemented, so merges branch_A into branch_B.
* There's more hacking on branches A and B.
* Branch_B gets merged into the trunk.
* Then we want to merge branch_A.
Guess what? Developer A can't use the tag he made when he branched off the trunk; he has to use the tag that hopefully developer B remembered to make when he merged branch_A into his work.
And that's a simple case. The canonical difficult case is the "criss-cross merge", where version A_1 is merged into B_3, and B_1 is merged into A_3, then we want to merge A_4 and B_4.
There is no "common base version" to use in this case even if you could figure out the tangle of string that is the branch histories with the miserable tools that CVS gives you.
I'm sorry if you worked heard learning how to use branches in CVS, but later SCMs, including git, do it so much better it's not even funny.
Perhaps it's hard to understand if you haven't experienced it, like trying to explain 3-D gaming to Charles Babbage, but the difference isn't remotely subtle. It's like the difference between a library card catalogue and Google.
Git's popularity is not due to Linus's personality cult. The static code analyzer that he wrote (sparse, pronounced s-parse) is also a cool piece of work that's been used routinely in Linux kernel development for years, but it doesn't get the kind of evangelism that git does.
Git has a lot of enthusiastic users because there's something to be enthusiastic about.
And we haven't even touched on one of Git's biggest advantages—it's so freaking fast that you actually use it differently.
All the moaning about Linus's comments and personality are irrelevant to the bottom line of his talk.
ReplyDeleteHis main points about SCM were: distributability is a better way to work, reliability and trust is important, and performance matters.
All of that is true and he convinced me that git is better at all of them than anything else.
So all the wannabe Linuses can go on bitching about his attitude toward crap, but personally when I decide on an SCM system, I'll be looking at git first.
Now, IF the git user interface is as difficult as some people claim, I'll be the first to tell Linus (and his git maintainer) to get their head out of their butts and clean it up. Because user interfaces are one of my pet peeves.
I can't stand developers who are geniuses at getting something to work - and then make it unusable by doing a crappy interface. And that's just about all developers, who I regard as "stupid and ugly" just like Linus does.
Linus should just shut up already. The only thing stupid and ugly that he pointed out to me was his own personality.
ReplyDeleteShut Up And Code! (SUAC)
Is being distributed useful in a small office environment? Well, I've found so with teams working on multiple projects. It also makes history operations lots faster, making examining history a more rewarding endeavour.
ReplyDeleteLinus certainly has a tendency to act arrogant when he's basically right. I disagree with this notion that "SVN promised so much" - it promised very little except atomic commits and a simplified (IMHO stupified) namespace. And on those it delivered.
yDNA, you merge like a mofo now? Great. A shame that no-one else can interpret those SVK merge breadcrumbs left all over the upstream repository. Still, I guess that's fine so long as only one person is working on each branch at a time. From the same computer.
svnmerge doesn't suffer from the same problem but its merge ability is retarded.
The merge tracking support in the upcoming SVN release, even if they don't mash it up, is just not going to be enough to solve the endemic problems that characterise it.
Anyone who glosses over the differences between source control tools as if it is as small a matter as the skin of a media player is demonstrating a dangerous ignorance of the real considerations involved. Engineers of source control tools that can see how they would fit the content-addressable filesystem core to git as a layer of their source control tool are on the path to understanding.
I agreed with Linus about merging. In my experience (although not many of merging), merging can be a nightmare. When something goes awfully wrong after the merge, there will be headaches and many sleepless night trying to trace the origin of the problem.
ReplyDeleteIn my previous project experience, we use branching for separate implementation on various OS.
Go Git Go!
ReplyDeleteSourceSafe, CVS, Subversion and even Perforce users tend to be against branching basically because their tools are quite bad when dealing with parallel development lines
ReplyDeleteI know nothing about SourceSafe, but I've used the other three a lot. It's true that CVS is "bad with parallel development lines"; branching (and operating on branches) is hard in CVS due to the repository format, but that is the least of CVS's problems; in my experience, the lack of change sets and atomic commits is far more limiting than the lack of branch management.
Subversion, however, has very efficient branching support—in fact, it's a constant-time operation. Subversion also has atomic commits and a crash-proof, append-only repository format. Merging is done using svnmerge, which supports cherry-picking and is very easy to use (some people may recommend SVK for merge tracking; it is a very bad idea for a number of reasons, the foremost being that it doesn't work). The only feature I miss in Subversion is a way to tag a revision, or a set of file/revision tuples, with a symbolic name (similar to tags in CVS, or labels in Perforce).
Perforce is loaded with advanced features, including full branching and merging support (with cherry-picking). As in Subversion, branching is a namespace operation. However, Perforce has an absolutely horrible user interface; it scales very badly in pretty much every dimension that matters; all client state is kept on the server; you can't have multiple working copies of the same branch on the same client; you can't do anything quickly and easily, except perhaps 'p4 sync'; and despite years of nagging the developers about it, there is still no way to produce a diff that will actually apply with patch(1).
The main problem with Linus (apart from his attitude) is that he does not understand that different people have different needs. Git is designed to fit the Linux development model, with changes flowing from branches to the trunk. Other projects (e.g. FreeBSD) have a development model where changes flow primarily from the trunk to the branches (it is becoming increasingly common for FreeBSD developers to fork a branch in Perforce to work on a specific feature, but each branches is usually abandoned once the feature has been merged wholesale into the CVS trunk). Subversion is very well suited to this model, and no matter what Linus (or anyone else) may think of the "CVS done right" slogan, it is efficient, reliable and easy to use.
CVS and SVN seemed adequate for merges, but then again I've only used them on simple projects.
ReplyDeleteClearCase is a merging disaster. First you have to update your "view," then you have to merge _from_ the target branch _to_ your own branch (backwards!), and then you have to merge _from_ your branch _to_ the target branch.
And if you screw up that exact sequence of events (or if someone checks in a file while you're waiting the endless hours for the merge to finish), you have to repeat the whole thing. Another thirty minutes down the drain.
ClearCase also requires manual conflict resolution in a lot of cases where it shouldn't. The three-way merge screen leaves a lot to be desired: all three columns are so narrow that you can't tell which is the source branch, which is the old target branch, and which is the new target branch.
Frankly, smoothness of workflow is as important to me as branching and merging. And for that, you can't beat SVN's integration into the shell via TortoiseSVN and its Mac cousin, SCPlugin (the latter still needs work, but shows promise).
You misunderstand, my anonymous brother. *Branching* is easy in CVS; it's the subsequent *merging* that is a screaming nightmare of eternal pain and suffering.
ReplyDeleteQuit complaining about Subversion and try TFS if you want to see real pain. It has just about everything you could need or want, and most of it works well enough to almost use. Subversion is not bad at all.
ReplyDeleteSince I haven't seen any Perforce defending, I'll chime in. I find Perforce to have the best branch/merge handling of any of the other SCM systems I've used (CVS, RCS, SourceSafe, SVN). You make a branch, make your changes, merge it back and then even propagate those changes to another branch with a reasonably small amount of effort. All non-conflicting changes merge correctly and just work. The dialogs could be a little easier but that's it. I could envision a better system but I've never seen it implemented. Even if it did get implemented, odds are they'd make other design decisions that would drive me batty (and hence my dislike for SourceSafe & CVS). So, since the mythical "perfect" SCM system doesn't exist, I'll take Perforce over anything else.
ReplyDeleteI'm not sure if the ability to have multiple repositories is a good thing for that many projects. It seems to me to be the antithesis to continuous integration, the paractice of keeping the build solid at all times.
ReplyDeleteI've used ClearCase on a small-ish development project - 12 devs over two years - and even with that we eventually had to hire a brainy (ie. expensive) contractor whose FULL TIME JOB was to merge the source code back into the main tree. No other project I've worked on, in ten years in this industry, has been able to afford that, so I avoid branching like the plague. Yes, there are "downs", and you have to be very careful what you check-in, because it goes straight into the main trunk, but with lots of unit testing it just-about works!
ReplyDeleteHi Sid,
ReplyDeleteAre you kidding?? I mean, a full time expensive contractor for doing the merges in a small 12 people team???
AFAIK Clearcase has a very good merging system (the folks running this blog have a pretty good one too), so I can't understand your problem... I mean, if you try the same with SVN you would be totally pissed off after two days...
I can believe a full-time merge manager for a 12-dev team. My project is smaller, uses branches, uses CVS, and is probably damned for it. We have one team member just doing merges and integration tests thereof and we still sometimes get screwed with bad merges. CVS merges are like quantum physics; each time you think you understand it it's just a little bit wierder.
ReplyDelete"If you have a hundred of intermediate branches spread through developers machines it will be much difficult to have a developer checking why a colleague made a certain change reviewing history, basically because the branches will be spread all over the network instead of at a single point..."
ReplyDeleteThis is untrue. When you merge, the histories are merged too. It's not like the 'private' repositories keep secrets.
Monotone was first, IIRC.
ReplyDeleteThe Subversion dev team mentioned long ago that kernel developers have a very different usage model than your typical software project:
ReplyDeletehttp://subversion.tigris.org/subversion-linus.html
Hi all Subversion lovers out there!!
ReplyDeleteCome on!! Let's get serious!! Subversion is just the sad Collabnet marketing campaign. Period. It takes ages to evolve, it doesn't implement proper merging yet... Just marketing to sell their bugtracking/project management stuff. Period!
So, yes, keep on using marketing stuff instead of a real system...
BTW Collabnet folks are trying to erase companies like Perforce, Vault, Accurev, Serena or the folks at this blog!
Have you ever tried Accurev? Plastic? Surround?? even Perforce? They are simply in a higher level than crap-svn... but yes... you've to pay!!!!
I wonder if you all would be using SVN if Accurev or Plastic or Surround were free...
Hi all,
ReplyDeleteTake a look here to see Plastic merging in action...
Isn't it better than what you get with free tools? ;-)
Isn't it easier just to use Microsoft Word's "Track Changes"
ReplyDelete!!! LOL
A lot of people that have commented probably do not understand how respect and evolution happens amongst hackers [used here in its original sense]
ReplyDeleteHardcore people like Linus don't get diplomatic about things. There's no time. You see something you don't like - you call it out, make a better tool [subjective claim, generally] and move on. The superior technology is the one that holds its ground. Somebody else will come and tell Torvalds to "git lost" [couldn't help it] and bow to their supreme SCM.
I've been called on bullshit before and I've called it on others. You sit down, you think about it, you decide whether you were indeed doing it or not. You move on either way. This is a guy that has looked at CVS and SVN a lot, I'm sure, and didn't just throw around [what have been perceived as] insults. He is interested in technology, not politics or business sense.
Cultural differences, as they say.
I'm just now finished evaluating a tool to replace the basilisk clearcase site we have. I'm impressed from AccuRev features and tweaks, while we compared it to Subversion... if only we heard of plastic two months ago it could have been a competitor to AccuRev. Guys you should do the marketing aspects more obtrusive.
ReplyDeleteGIT sounds good, this is the first time I hear him speak. And I have to say, he comes across like an arrogant prick.
ReplyDeleteThere are advantages to both Distributed and Central systems. Here's my (pro-Bazaar) response to Linus' talk: Version Control: The Future is Adaptive.
ReplyDeleteHi,
ReplyDeleteThis article is good and informative.
Software Development Company
inaequitas, I guess being "hardcore developer" releases you from having to have the slightest respect to the people who came to listen to your speech, huh?
ReplyDeleteI say, this Linus Torvalds truly is a git.
inaequitas, so basic human decency is now below this "hardcore man"?
ReplyDelete"If you have a hundred of intermediate branches spread through developers machines it will be much difficult to have a developer checking why a colleague made a certain change reviewing history, basically because the branches will be spread all over the network instead of at a single point..."
ReplyDeleteIf the change is found in some repository, all of its history will be too (and all the history of all branches that went into it)
People should read this.
ReplyDeleteTFS ::shudder::
ReplyDeletefor me... the requirement of only having one working copy per computer is DAMNED STUPID
For those who are suggesging "Oh Linus is arrogant, Linus is bad, Linus is such a git, etcetera", I have one thing to say.
ReplyDeleteIf anybody has the right to be going off at Google it is Linus Torvalds for sure. They have become so powerful and stinkin rich mainly because of his work.
Android = Linux, Google's servers run Linux, and Chromium OS is Linux too.
So definitely if anything Linus has the right to tell Google off for stuff he thinks is wrong.
I completely agree with Linus. I think no one will object that Perforce likes to play around with line endings, which is a pain when you have mixed EOL files or when you wrap a repository into git-p4. This simply violates the principle by which a repository will give you back exactly what you put in it.
ReplyDeleteI'm using Perforce daily at work, but it simply is too old-school to be still relevant. It imposes its own way of coding, and people are more incline to make the big do-it-all commits with it, hard to revert or to move around. I just don't see the point of using it, even for a one-person project.
Last but not least, its price is just shameless.
One big issue that git has to face though is exclusive checkout. Sure I can work disconnected and all, but if two artists update a picture or a music, then it's the end.
The theory is that there should be a merge tool for everything, but in practice this is extremely hard or even impossible. Take this example: I add a character to a picture, in an empty spot. My co-worker adds a big magnifier, making the whole picture look as if it was observed through the latter. The magnifier adds distortion and light effects. Good luck in merging that now.
And while speaking of binary resources, git should also get better at managing big files. Going out of mem every now and then is just not acceptable. I'm aware of git-annex, but it adds extra steps and is Linux-only, while - unfortunately - most companies are stuck to Windows or have mixed OS.
@King_DuckZ So, if you miss exclusive checkout and big binaries... plasticscm.com/games... check it!
ReplyDelete@Pablo: thanks, I'm having a look before discussing about Plastic to the other team members.
ReplyDeleteSome features look nice, but I'm having troubles with the installation and I'd like to make sure about a few things before I go on. I didn't find any answer on the website, so I hope I can ask you:
1 - does Plastic rely on the read-only flag?
2 - why do you provide a Visual Studio plugin? does Plastic need to know about everything you do/want to do? If so, what happens if I use other editors?
3 - can you easily commit only a part of a file?
4 - can you easily change history (ie: interactive rebase in git)
5 - does Plastic enforce a certain line ending, like Perforce?
6 - is there an easy way to see the unified diff instead of the side-by-side I saw in the screenshots?
7 - is there an easy way to produce and apply patches?
8 - can you blame, and can Plastic look through merges in order to report the correct author of a certain line?
9 - can you do everything from the CLI?
@King_DuckZ: thanks for the interest! Hey, why don't you reach us at the forum: www.plasticscm.net, and we continue the conversation there?? This is a very oooold post so it would be better to follow up on a new thread on the forum...
ReplyDeleteThanks!