Slashdot Mirror
Linus on Subversion, GPL3, Microsoft and More
victor77 writes "Linus has repeatedly slammed Subversion and CVS, questioning their basic architecture. Subversion community has responded...how valid is Linus's statement?" This and many other subjects are covered in this interview with Linus.
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
I've never used git on any project big enough to have multiple developers, but I use git for my one-man-projects for the simple fact that it's so easy to create a repository.
Simply move the directory you're working in and type 'git init' and you're off and running. If you're developing the same code on multiple machines, it's simple to develop on them independently and still sync relevant changes. Frustrating.
With SVN, you have to set up a central repository (not difficult, but tedious) and if you're working with the code on multiple machines that aren't always on the same network you either have to have a SVN repository on each one and manage syncing them somehow, or one machine can't make commits when the other isn't on the network. Frustrating.
I still find git to be a little confusing (especially in regards to warnings seen when pushing or pulling changes from one repository to another and merging branches), but I've decided that even if git isn't the best answer, a distributed version control system is closer to the Right Thing than the old way of doing it (for my purposes, at least).
*sigh* back to work...
Subversion works, but like Linus says, it's nothing wonderful. You can hardly point at some feature of it and say it was the product of a genius. It does CVS right, and that's about it.
But SVN is limiting. For example I have a fork of the Second Life source, and SVN was PAIN for that. I ended up switching to SVK because it was the first thing I found that could sync with a SVN repository (which is what LL hosts), but Git would probably be also a fine choice as well.
SVN's problem is that when you want to branch somebody's source but still follow it by merging improvements it becomes really painful. You have to use svn-load-dirs, which is a hack. You have to give it megabytes of source to process, which can suck really badly when you've got your SNV repository hosted externally so that other people can access it.
As to my 'iconic image', I tend to dislike that part personally. I'm not a great public speaker, and I've avoided travelling for the last several years because I'm not very comfortable being seen as this iconic 'visionary'. I'm just an engineer, and I just happen to love doing what I do, and to work with other people in public.
This, people, is the key difference between Linux and Microsoft, and even Apple. Steves Ballmer and Jobs both want to be seen as visionaries, as all-knowing technological sages of our time. That isn't neccessarily a bad thing, as we've seen with the way Jobs has turned Apple around since he took over, but it does explain the difference between the philosophies of the groups: Apple and Microsoft take the approach of throwing new features in whenever they find them, so as to be seen as forward-thinking and 'next-gen', and sometimes that works and sometimes it doesn't - Spotlight being an example of something that does work (yeah, there had been desktop search before, but nothing quite that efficient and right-on-the-desktop in what can be called the 'Big 3' operating systems), and things like the are-they-in, are-they-out dropped features from Vista being an example of something that doesn't.
Linux, however, taking it's cues from Linus, approaches things from an engineering perspective. Visionary? That's all well and good, but will it run the risk of breaking? Yes? Then it's not going in. When you don't have a product to sell, it's a lot easier to base your development priorites on a more sound engineering base. Therein lies the difference; Jobs and Ballmer see themselves as visionaries, while Linus - who, whether he likes it or not, is the 'spiritual leader' of the Linux community - sees himself as 'just an engineer'. (Of course, the point could be made that Linus has the luxury of only being concerned with the kernel, where security and stability are the key things and form over function is rarely if ever required - do the likes likes of Mark Shuttleworth, Matthew Szulik, etc see themselves as engineers, or as visionaries?)
Dealing with lawyers would be a lot less tedious if they all looked like Casey Novak.
If CVS isn't broken, I have a three-legged ladder I'd like to sell you. I'll even set it up in the parking lot and, with but a modest presence of mind, balance myself motionlessly on the very top step to prove how very not-broken it really is. On one foot. And I'll juggle, too.
CVS is what happens when you've roped yourself up into some high, awkward, inaccessible place, then you discover you brought along the wrong toolbox. Subversion is a fancy pair of vise-grips with rubber handles: doesn't hurt your hand so much when you have to grasp with extreme force the bolt head with no remaining flat edges, because you're too damn lazy to rope yourself back down to get the tool you should have used in the first place.
Wish I had some mod points but I believe you make a really good point.
But to be sure, allow me to draw a parallel to help illustrate what I understood:
It's not that Walmart is a crappy store... it's not and they generally have some pretty good stuff there. It's the people who shop at Walmart that gives Walmart its reputation.
Is this pretty much what you're saying about Microsoft stuff? It's not that the products are bad--they're not. It's the people who use Microsoft products that give Microsoft its bad reputation.
I think there is a lump of truth to this assertion. Microsoft is a lot more ubiquitous and available than many competing products. Certifications demonstrating expertise typically only require enough money and a list of answers to acquire.
I think this is an assertion that requires some meditation: It's not the products, it's the users...
I'm not so sure about that.
I work for a company that got burned on outsourcing its support to India. That said, the one guy we hired off of the outsourcing company knows more about Linux than the rest of our system administrators put together. To this day, if anybody has a question that we've found unanswerable by an American employee, we will send him a message.
Haec merda tauri est. Ceterum censeo Carthaginem esse delendam.
And do try to go easy on the phrase "paradigm shift" in your explanation even if this is one; marketdroids love over-using it and it's come to be a code phrase for "same old, same old". Focus on how things have changed for you and you'll get a better response.
"Little does he know, but there is no 'I' in 'Idiot'!"
There are lots of clients to choose from at the tigris.org site. If you don't want or need a file browser plug-in/Explorer extension/IDE integration, there are a number of apps to choose from. Granted, TortoiseSVN and Subclipse track the Subversion releases more closely than the others. Personally I use a combination of TSVN with Kdiff3. I also use AnkhSVN in Visual Studio, just for the auto-add and file icons.
In exactly what way does a distributed source code management system change the way you work?
It gives you private branches and commits, which allow you to work with the power of a VCS, but without having to pollute the main repo with dead ends, poorly written changes, and experiments. It also allows for true disconnected operation, and allows any developer to "pull" from another developer, again without having to pollute the master repository.
And specifically with git vs. SVN, git offers true branches and tags (unlike SVN's bizarre, nonsensical "simulations"), and true merges.
And do try to go easy on the phrase "paradigm shift" in your explanation even if this is one; marketdroids love over-using it and it's come to be a code phrase for "same old, same old". Focus on how things have changed for you and you'll get a better response.
It (git and distributed VCS) is a "paradigm shift" the same way that, say, the relational model is a paradigm shift over the network model. It generalizes the problem and strips it down to certain fundamental concepts, and makes those concepts available to you directly, instead of under a layer of ill-conceived and limited operators.
For instance, in SVN, how do you move a changeset from the tip of one branch to another? You can't. It's not allowed by the model, even though in terms of more fundamental operations, it's easy to describe. But in git, you can. Just cherry pick it to the new branch, then move the tip of the old branch back one changeset (the "dangling" changeset on the old branch will eventually get garbage collected). You could also write your own "git-move-changeset" command using the existing low-level git commands.
Instead of considering the deeper, underlying issues, the SVN team just cloned CVS's behavior and made it cleaner. Too bad.
That's exactly what a "paradigm shift" is: finding the deeper, fundamental operations and then showing how the existing systems are just subsets of that functionality.
To some extent, the heavy influence of India-based developers on the kernel is due to IBM having a major lab there, which is being emulated by a number of other Linux-backing corporations. The quality of technology education seems exceptionally high from what I can see, and to be honest, the Indian culture seems to be oriented towards higher things than money.
Have you got your LWN subscription yet?
When I first heard this crap about Linus not liking SVN I was thinking what a dork, SVN is great. But then this post opened my eyes. This reminded me of all the crap I have to deal with in SVN, it's a pain. I also have to be honest, I've never heard of git, now I must find out more about it.
Have you got your LWN subscription yet?
"What happens in the large corporate is, devs end up keeping their "working copy" of the code on their local machine because"
Because they usually don't know the tool or the tool's potential.
"if they just checked their experimental/broken stuff in, other devs would complain"
I've been working both on Subversion and CVS (among others) and never experienced it. Why? Maybe because I knew about the use of the tool; about how to deploy "this_is_head" moving tags and how to properly use branches, so one developer's experiments doesn't break other's work and still they are "near enough" to main development lines to merge frecuently as needed (and no, abandoned branches were not a problem since they can be pruned out when needed no more).
"Same for creating branches in the central repository, if you are doing it for you own experiments you will get unpopular fast."
That's even more extraneous. Why other developers should have to give a damn about branches they don't use? Clearcase, for instance, is mostly based on the "developer branch" concept to great amount and while the product isn't the most popular among developers, it is not because the "developer branch" concept which is the one they tend to like the most.
"So what happens instead is, a dev makes changes to their checked out copy and does not check in for days or weeks at a time"
Because:
a) They ignore the tools possibilities
b) Their company ignore the advantages of founding proper SCM (people, tools and time) and the SCM tool manager only too often ends up being one of them, or someone without the knowledge and too overburden to do a proper work.
"then bits of this work get lost for one reason or another"
And then the proud git user's hard disk fried and his git repo is lost all the same. And then the devolper gets hit by the bus, or resigns and nobody understands what's the hell on his harddisk.
"Meanwhile, development on the trunk eventually orphans the experiment, merging is too much work"
That's just the natural outcome of a too long lived branch, no matter is you use a central or a distributed repo. It is the code the one that distances, not the tool that manages the code.
Subversion should have proper branching and merging. CVS should properly manage whole hirarchies. Both of them should properly handle deltas. But they are all limitations of the tools, not flaws on the paradigm. Surely distributed SCM has his place but centrally managed SCM has it too and it's much more important the former than the latter in corporate environments. Maybe in a future there will come a tool that will allow seemlessly for proper central or distributed SCM, and I can tell I'll be glad for it, but I can assure that the central paradigm will stay strong within corps, because that's what's needed.