Well, when you revel in your own ignorance of the technology you are trying to use then it's no surprise you run in to friction. 5 minutes on google could have cleared up most of his gap in understanding how SVN works.
Googling your questions and figuring it out does not an interesting article make. I find this a fine counterpoint to people who come to git from other version control systems and baulk when they see it, it's an interesting alternative perspective to the whole "good UI/bad UI" discussion.
The OP could just have used git-svn. While it's not totally perfect, it allows him to have the feature branches he likes so much and it would allow him to do (local) rebases to clean his commits.
I did so in our project for a long time (about a year - never had issues) until I was sufficiently sure that everybody was on the boat for git, so I could be anal about the quality of my commits and use git to its fullest while everybody else could continue to use svn.
Of course once we needed public branches, everybody had to move to git because as I'm used to saying "while SVN perfect for branching, it just plain can't do merges" and from time to time, you just got to merge, so you should probably be using a system which actually allows you to.
This was roughly how I got my previous company onto Bazaar, I was using bzr-svn as my svn client, and gradually more devs switched to my approach - and discovered it was better.
At some point down the line we swapped the server over as well.
In my experience, using a system that tries to bridge between two technologies like Git and SVN will result in having to deal with a lot more weirdnesses than each technology individually.
In general, the amount of bullshit you'll have to deal with from a piece of software is inversely proportional to the number of users of that software. And the number of users of git-svn is much lower than both SVN's and Git's.
It's down to how you work, who you're working with, and the processes you have in place.
My personal motto is just "don't break the build". It seems messy to me to create a ton of branches with broken stuff on them, having to remember the state of everything, what's been merged, what hasn't. I'd rather just write code to a single trunk. If I need to do big arch changes, I do them in bits that don't break the build.
Time is linear. So is my trunk. I develop linearly. I don't think in branches.
I can totally understand that other people see things a different way, and prefer to work like that. But I cannot. I tried. It was awful, painful and a waste of time.
So enough with the "This is better than this" mentality :)
Well, first, one of the points of branches is "don't break the build" since you always know that master is an appropriately tested version of the code. Branches give you feature isolation.
Suppose that while developing a feature, you realize that a piece of code is buggy. In your view of the world, where everything is linear, either you drop everything you're doing and fix that bug, or file a bug with the tracker, deferring it until someone has time to fix it.
But morally, the second one is just a branch--time in this case isn't linear. You (or someone else) will have to change contexts at some point and fix the bug. If it's after your feature has been committed, then you have to do it on code which may have churned quite a bit since you filed the bug.
So if you used branches, you would just create branch for the fix. If it gets committed into master before your feature, you could obtain upstream changes. If it gets committed after your feature, you can use rebasing to replay that work on top of the significantly changed code.
If you need to do big arch changes, you still do them in bits such that every build isn't broken. You just do them in a branch, so that nobody else sees them until they are completely ready.
Note also that, with git's powerful tools, you have the option (which is usually taken, these days) to rebase your branches into master, not merge them. So, when you published your changes to the world (git branches are local, nobody else can see them) you could still show the world a linear line of development if you so pleased.
So it may not be a "this is better than this" mentality, but you definitely do lose a significant amount of expressiveness and flexibility for no reason. Branches are painless (in git) and certainly not a waste of time (in that they actually streamline the development process). Can you describe the situation in which you thought that was the case?
Works when its just you and friends, and you talk a lot, and are working on the same project and release schedule.
Change any of that, and you need a better technique.
There are lots of different ones, and switching between them is a mind-bend, so folks gripe a lot. But you'll likely have to learn one sometime, probably sooner than you'd like.
Please don't be the guy that gripes and drags his heels. There are legitimate reasons to need source control. Your personal convenience is one of the decision factors, but a very minor one.
I think there are some features where SVN is superior to Git (dealing with large binary files?) but I think you could basically use Git in the fashion you describe, and it would be a better experience than SVN. Just being able to quickly checkout old versions without touching the network is awesome.
On the other hand, as soon as you bring a bunch of people working on a project together, isn't the development inherently non-linear, and there's the possibility that you will need to deal with (implicit) branches? I guess if every person committed to the trunk frequently you wouldn't need to.
> So enough with the "This is better than this" mentality
I understand the sentiment, and the desire to avoid flamewars and endless bitching about tools, but no thanks. If I never have to deal with CVS telling me that every single file in my tree has a conflict in it again, I will be very pleased. If no one had a "This is better than this" mentality, we might not even have the choice of Git (or even SVN for that matter).
> I wanna make a small change to the code to add [Feature X], I’ll just make a little branch, alright?
I suppose this is a product of growing up on Git. Growing up on SVN, I'd just add the feature.
> I was looking for the SVN equivalent of .gitignore: A list of file patterns that do not get source-controlled, ever. \ It turned out that SVN’s ignoring mechanism is far more complicated than that....
You're perfectly able to use a '.svnignore' file, if you like. In fact, the "Ignoring unversioned files" chapter (http://svnbook.red-bean.com/nightly/en/svn.advanced.props.sp...) describes how to import .cvsignore files, which are another predecessor to .gitignore files. (Note to OP: If you hated SVN, just stay far, far away from CVS). SVN gives you a lot more rope with respect to properties if you want to do more complex stuff with properties (and yes, you can probably hang yourself with this rope - see http://svnbook.red-bean.com/nightly/en/svn.ref.properties.ht... for some use cases).
The list of file patterns that don't get version controlled is known by Subversion as the svn::ignore property. The property syntax is similar to that of .gitignore files; simple .gitignore files are likely to be 100% compatible (notable differences are: no comments (but if you have a file called '# These files are generated by the compiler', we have other problems), and no `/` character support). You set this property (like all properties in SVN) with the `svn propset` (aka `svn ps`) command. See
http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.propset... for documentation. You can use files as arguments to this command, and you can set it recursively.
Run the following command (which doesn't seem baffling) in the root of your working copy to set your ignore properties from a global ignore file:
svn propset --recursive --file .svnignore .
Note that you'll need to run this command every time that you edit the .svnignore file.
2) In subversion you have to run a 44 character long command with one subcommand, two flags, and two file arguments. In git you have to do.... nothing.
Complaining about tools of fairly disingenuous when he didn't make the effort to learn svn. Also who takes work based on the version control system? Language I could understand.
Right, it's definitely surprising that he could decide to outright not take a job that doesn't use Git. Hell, my last job used Source Safe, it was a please to be able to use freaking SVN on side projects in comparison at that point!
"SVN [is] to Git what Windows 98 was to Windows XP."
"SVN is a slightly crappier version of Git."
to
"SVN is a version of Git in which every time you want to start a branch or merge it back, you have to sacrifise a young virgin to the source-control gods."
But I couldn't figure out if he got to "SVN is not a version of Git, just like Unix is not a version of Windows."
It's because the only version control system he's been exposed to before SVN is Git, so he understands version control in terms of Git. Every version control system is then like Git, plus some things and minus others. Hence these descriptions.
That was my thought too. I moved to Git recently, but it wasn't that long ago that I was rejoicing over how awesome SVN was, simply because I could rename things (files! directories!) easily and still reasonably track history.
Hmm, was it SCCS or RCS that allowed you to "lock" files and then go away for the weekend, effectively shutting out the rest of your team?
My impression is that the issues people have with branching in Subversion is down to a workflow problem (the people and their actions) more than the software itself.
Yes, Git does branching and merging way better than Subversion. Git branching is easier, lighter weight, and it understands playing back revisions to avoid conflicts very well.
But Subversion isn't a nightmare if you have procedures in place that everyone on the development team uses and if the development team talks to each other on a regular basis about it. This whole procedures and talking to each other thing can be hard for some people and if the mentality of the group isn't good about it when you join, you'll have an experience like the OP.
The whole talking to each other thing also breaks down if the team consists of thousands of people spread all over the world. Git was specifically designed with this in mind.
I worked once on a project which used a Pick database. If you don't know what that is, thank the fates. While I worked on it, I dutifully read the mailing lists and such to learn what I could about this technology. This experience taught me that every awful piece of technology has a halo of zealots who think it's the greatest, and is just now (still) on the verge of taking over its field. And should you hint that there might be anything better, they have a litany of reasons why you are the problem, because you don't understand it. The whole thing is about as odd as watching the domestic life of someone who has married their vacuum cleaner.
Some of the defenders of subversion here reminded me of that experience. The more truculent defenders slash at those who point out its deficiencies with remarks about their ignorance of subversion, and if you don't take a couple of weeks out of your schedule to learn its thorny ways then you deserve your problems. The milder defenders will equivocate and claim that its just a preference, and that subversion isn't nearly as painful as long as everyone on the team always unfailingly follows this list of 178 rules on what not to do.
My major problem with the people attacking svn is often that they dismiss that svn has a different set of features that may or may not suit your workflow better than git's. Every feature of git may be liability in some environments
* I might need a controlled server with an audit-trail where any ability to rewrite history is a liability. SVN wins hands down here.
* I might want the ability to lock binary files since my repo is mainly a set of designs created by the gfx people. SVN wins.
* I might want the ability to mount the repo as webdav folder since I want accountants to store their XLS-Files in there without knowing what's that funky version control system. Git can't do.
* I might want to commit on the road, in the plane, in my cabin in the woods. SVN fails hard.
* On the contrary, maybe my environment is such that the svn server is on the local network and I actually feel uncomfortable with people running around with their laptops and all of my VCS history on them. Git fails hard.
Point is: SVN is a serious VCS. It's better suited to some workflows than others, same as git. Which tool is better depends on what you're doing and what the environment you're doing this in. This is what the author of the original article forgets about. And this an ignorance that I often see in my fellow developers - and something I can't stand. The most awful piece of technology might have a spot where it really really fits.
(disclaimer: I currently use git, but have been a very happy svn user for years.)
It made me irrationally happy to read your blog. Here in Germany it is impossible to find any company that uses Git or the like. Everywhere you see CVS (that is the father of SVN) or maybe even NO versioncontrol at all. Sometimes there is a very modern company that has some part of their code in SVN (or is a start-up and has no big code base yet). Dreaming about using git for other things then playing around at home is too fantastic for me. Feel lucky that you can get your employers to change to git so easily!
Btw. if anybody knows IT companys in or near Berlin, who use modern technologies like Python or Git, please (please!) tell me!
Maybe traditional VCS systems fit the German mindset, if such a thing really exists, better. Centralized, more structured, server-based and encouraging a more methodical workflow - seems like it might appeal to Germans.
I grew up in Germany but spent most of my working life in the US. My experience is that the overall mentality of engineers in Germany is somewhat different, more of a focus on process and less on experimentation, but it's a matter of degrees. I'd be surprised if the percentage of shops using no version control is higher in Germany, though.
The interesting thing about this otherwise misguided post is that there are now people who started out on Git who are struggling to adapt the older, server-based workflow.
It's really not about Git vs. SVN. It's about distributed vs. centralized VCS. I think programmers are realizing that there's truly an advantage to the DVCS approach but the discussion quickly becomes emotional and irrational. The net result of sucks-vs-rocks discussions are just damage to the cause of newer technologies.
I've used RCSs (RCS,PVCS,VSS(^%$#^$%),MKSSI,CVS,SVN) for so long that the latest versions of SVN, which support branching (though not so well), seem very comfortable and luxurious. The Eclipse plugins like Subclipse or Subversion for updating and merging files make CVS/SVN almost is a pleasure to use.
However, there are workflows and tasks that DVCS systems support much more naturally and it's that aspect that should be discussed.
So you completely change a way two of your clients do version control because you're a Git fanboy? I might use Git, an iMac, and Ruby... but I'd never try to change someones tech just because I prefer a different solution to the one they have in place and might have fully researched beforehand.
I agree with you deep down... I dislike SVN deeply (and I have to use it everyday), but you haven't even used it enough to be able to give an informed opinion on it. Just like Apple fanboys try to evangelize people because "Windows sucks and Macs are so much cooler and Steve Jobs says so"
BTW, the biggest irony in my opinion, is that you're using Windows, which if you added Visual Studio to it (yes I know you're a pythonista, not the point) would mean that SVN is the [sic] BESTEST solution for your source control needs. Which is also a prime example that the latest technology is not always the best, and that you should always make this decisions on a case by case basis.
Also, I'm working on a branch in SVN right now, and I merged a couple of branches to trunk last friday. This is not rocket science... A good developer adjusts to the clients needs, not the other way around.
Is Git 100% social/public? Can code be private? And last question: is it secure enough to where enterprise companies (not just tech hipster startups) use it?
Nothing about git makes it either "social/public" or private. You can use it yourself entirely on our own workstation, you can use it on a company server only your devs have access to, and you can of course make public repos on your own hardware or with hosted solutions such as github.com.
Git is also arguably more secure than many other VCSs since it (in a very very small and generalizing nutshell) works by creating a directed graph of SHA sums. You can't change a file and propagate those changes to other people without everyone being well aware of what has been done. Not unless you can compute useful code that collides with existing code... check out what linus has to say about that improbability some time^ ;).
No, security shouldn't be the issue for enterprise companies, though scalability is often cited as a potential issue. If you currently use perforce to a heavy degree, you might have some issues with going to git. This is not to say that git cannot work for very large companies, it probably just isn't going to work well if you put every project in your large company in a single one or two repos (as many companies do with perforce). It'll handle large projects fine however, it handles the linux kernel like a breeze.
The Linux kernel is on Git. Thousands highly skilled developers use it to manage one of the biggest software projects in the world. That's how mature a technology git is.
[+] [-] mberning|14 years ago|reply
[+] [-] burgerbrain|14 years ago|reply
[+] [-] pilif|14 years ago|reply
I did so in our project for a long time (about a year - never had issues) until I was sufficiently sure that everybody was on the boat for git, so I could be anal about the quality of my commits and use git to its fullest while everybody else could continue to use svn.
Of course once we needed public branches, everybody had to move to git because as I'm used to saying "while SVN perfect for branching, it just plain can't do merges" and from time to time, you just got to merge, so you should probably be using a system which actually allows you to.
[+] [-] glenjamin|14 years ago|reply
At some point down the line we swapped the server over as well.
[+] [-] cool-RR|14 years ago|reply
In general, the amount of bullshit you'll have to deal with from a piece of software is inversely proportional to the number of users of that software. And the number of users of git-svn is much lower than both SVN's and Git's.
[+] [-] mibbit|14 years ago|reply
It's down to how you work, who you're working with, and the processes you have in place.
My personal motto is just "don't break the build". It seems messy to me to create a ton of branches with broken stuff on them, having to remember the state of everything, what's been merged, what hasn't. I'd rather just write code to a single trunk. If I need to do big arch changes, I do them in bits that don't break the build.
Time is linear. So is my trunk. I develop linearly. I don't think in branches.
I can totally understand that other people see things a different way, and prefer to work like that. But I cannot. I tried. It was awful, painful and a waste of time.
So enough with the "This is better than this" mentality :)
[+] [-] rpearl|14 years ago|reply
Suppose that while developing a feature, you realize that a piece of code is buggy. In your view of the world, where everything is linear, either you drop everything you're doing and fix that bug, or file a bug with the tracker, deferring it until someone has time to fix it.
But morally, the second one is just a branch--time in this case isn't linear. You (or someone else) will have to change contexts at some point and fix the bug. If it's after your feature has been committed, then you have to do it on code which may have churned quite a bit since you filed the bug.
So if you used branches, you would just create branch for the fix. If it gets committed into master before your feature, you could obtain upstream changes. If it gets committed after your feature, you can use rebasing to replay that work on top of the significantly changed code.
If you need to do big arch changes, you still do them in bits such that every build isn't broken. You just do them in a branch, so that nobody else sees them until they are completely ready.
Note also that, with git's powerful tools, you have the option (which is usually taken, these days) to rebase your branches into master, not merge them. So, when you published your changes to the world (git branches are local, nobody else can see them) you could still show the world a linear line of development if you so pleased.
So it may not be a "this is better than this" mentality, but you definitely do lose a significant amount of expressiveness and flexibility for no reason. Branches are painless (in git) and certainly not a waste of time (in that they actually streamline the development process). Can you describe the situation in which you thought that was the case?
[+] [-] JoeAltmaier|14 years ago|reply
Change any of that, and you need a better technique.
There are lots of different ones, and switching between them is a mind-bend, so folks gripe a lot. But you'll likely have to learn one sometime, probably sooner than you'd like.
Please don't be the guy that gripes and drags his heels. There are legitimate reasons to need source control. Your personal convenience is one of the decision factors, but a very minor one.
[+] [-] spacemanaki|14 years ago|reply
On the other hand, as soon as you bring a bunch of people working on a project together, isn't the development inherently non-linear, and there's the possibility that you will need to deal with (implicit) branches? I guess if every person committed to the trunk frequently you wouldn't need to.
> So enough with the "This is better than this" mentality
I understand the sentiment, and the desire to avoid flamewars and endless bitching about tools, but no thanks. If I never have to deal with CVS telling me that every single file in my tree has a conflict in it again, I will be very pleased. If no one had a "This is better than this" mentality, we might not even have the choice of Git (or even SVN for that matter).
[+] [-] tytso|14 years ago|reply
[+] [-] reemrevnivek|14 years ago|reply
I suppose this is a product of growing up on Git. Growing up on SVN, I'd just add the feature.
> I was looking for the SVN equivalent of .gitignore: A list of file patterns that do not get source-controlled, ever. \ It turned out that SVN’s ignoring mechanism is far more complicated than that....
You're perfectly able to use a '.svnignore' file, if you like. In fact, the "Ignoring unversioned files" chapter (http://svnbook.red-bean.com/nightly/en/svn.advanced.props.sp...) describes how to import .cvsignore files, which are another predecessor to .gitignore files. (Note to OP: If you hated SVN, just stay far, far away from CVS). SVN gives you a lot more rope with respect to properties if you want to do more complex stuff with properties (and yes, you can probably hang yourself with this rope - see http://svnbook.red-bean.com/nightly/en/svn.ref.properties.ht... for some use cases).
The list of file patterns that don't get version controlled is known by Subversion as the svn::ignore property. The property syntax is similar to that of .gitignore files; simple .gitignore files are likely to be 100% compatible (notable differences are: no comments (but if you have a file called '# These files are generated by the compiler', we have other problems), and no `/` character support). You set this property (like all properties in SVN) with the `svn propset` (aka `svn ps`) command. See http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.propset... for documentation. You can use files as arguments to this command, and you can set it recursively.
Run the following command (which doesn't seem baffling) in the root of your working copy to set your ignore properties from a global ignore file:
Note that you'll need to run this command every time that you edit the .svnignore file.[+] [-] burgerbrain|14 years ago|reply
1) "a global ignore file"
2) In subversion you have to run a 44 character long command with one subcommand, two flags, and two file arguments. In git you have to do.... nothing.
[+] [-] parfe|14 years ago|reply
edit: replaced "south" with "work" stupid phone.
[+] [-] dbattaglia|14 years ago|reply
[+] [-] pessimizer|14 years ago|reply
"SVN [is] to Git what Windows 98 was to Windows XP." "SVN is a slightly crappier version of Git."
to
"SVN is a version of Git in which every time you want to start a branch or merge it back, you have to sacrifise a young virgin to the source-control gods."
But I couldn't figure out if he got to "SVN is not a version of Git, just like Unix is not a version of Windows."
[+] [-] unwind|14 years ago|reply
At least that was my take.
[+] [-] praptak|14 years ago|reply
FACEPALM. It is about as accurate as saying that Git does not have branches, just a "refs/heads" folder that you manually copy your code into.
[+] [-] akent|14 years ago|reply
[+] [-] kaffeinecoma|14 years ago|reply
Hmm, was it SCCS or RCS that allowed you to "lock" files and then go away for the weekend, effectively shutting out the rest of your team?
[+] [-] bradfa|14 years ago|reply
Yes, Git does branching and merging way better than Subversion. Git branching is easier, lighter weight, and it understands playing back revisions to avoid conflicts very well.
But Subversion isn't a nightmare if you have procedures in place that everyone on the development team uses and if the development team talks to each other on a regular basis about it. This whole procedures and talking to each other thing can be hard for some people and if the mentality of the group isn't good about it when you join, you'll have an experience like the OP.
[+] [-] mansr|14 years ago|reply
[+] [-] numeromancer|14 years ago|reply
Some of the defenders of subversion here reminded me of that experience. The more truculent defenders slash at those who point out its deficiencies with remarks about their ignorance of subversion, and if you don't take a couple of weeks out of your schedule to learn its thorny ways then you deserve your problems. The milder defenders will equivocate and claim that its just a preference, and that subversion isn't nearly as painful as long as everyone on the team always unfailingly follows this list of 178 rules on what not to do.
[+] [-] Xylakant|14 years ago|reply
* I might need a controlled server with an audit-trail where any ability to rewrite history is a liability. SVN wins hands down here.
* I might want the ability to lock binary files since my repo is mainly a set of designs created by the gfx people. SVN wins.
* I might want the ability to mount the repo as webdav folder since I want accountants to store their XLS-Files in there without knowing what's that funky version control system. Git can't do.
* I might want to commit on the road, in the plane, in my cabin in the woods. SVN fails hard.
* On the contrary, maybe my environment is such that the svn server is on the local network and I actually feel uncomfortable with people running around with their laptops and all of my VCS history on them. Git fails hard.
Point is: SVN is a serious VCS. It's better suited to some workflows than others, same as git. Which tool is better depends on what you're doing and what the environment you're doing this in. This is what the author of the original article forgets about. And this an ignorance that I often see in my fellow developers - and something I can't stand. The most awful piece of technology might have a spot where it really really fits.
(disclaimer: I currently use git, but have been a very happy svn user for years.)
[+] [-] erikb|14 years ago|reply
Btw. if anybody knows IT companys in or near Berlin, who use modern technologies like Python or Git, please (please!) tell me!
[+] [-] zwieback|14 years ago|reply
I grew up in Germany but spent most of my working life in the US. My experience is that the overall mentality of engineers in Germany is somewhat different, more of a focus on process and less on experimentation, but it's a matter of degrees. I'd be surprised if the percentage of shops using no version control is higher in Germany, though.
[+] [-] cool-RR|14 years ago|reply
What happened to "Vorsprung durch Technik"?
[+] [-] jurre|14 years ago|reply
[+] [-] moeffju|14 years ago|reply
[+] [-] zwieback|14 years ago|reply
It's really not about Git vs. SVN. It's about distributed vs. centralized VCS. I think programmers are realizing that there's truly an advantage to the DVCS approach but the discussion quickly becomes emotional and irrational. The net result of sucks-vs-rocks discussions are just damage to the cause of newer technologies.
I've used RCSs (RCS,PVCS,VSS(^%$#^$%),MKSSI,CVS,SVN) for so long that the latest versions of SVN, which support branching (though not so well), seem very comfortable and luxurious. The Eclipse plugins like Subclipse or Subversion for updating and merging files make CVS/SVN almost is a pleasure to use.
However, there are workflows and tasks that DVCS systems support much more naturally and it's that aspect that should be discussed.
[+] [-] sp4rki|14 years ago|reply
I agree with you deep down... I dislike SVN deeply (and I have to use it everyday), but you haven't even used it enough to be able to give an informed opinion on it. Just like Apple fanboys try to evangelize people because "Windows sucks and Macs are so much cooler and Steve Jobs says so"
BTW, the biggest irony in my opinion, is that you're using Windows, which if you added Visual Studio to it (yes I know you're a pythonista, not the point) would mean that SVN is the [sic] BESTEST solution for your source control needs. Which is also a prime example that the latest technology is not always the best, and that you should always make this decisions on a case by case basis.
Also, I'm working on a branch in SVN right now, and I merged a couple of branches to trunk last friday. This is not rocket science... A good developer adjusts to the clients needs, not the other way around.
[+] [-] gte910h|14 years ago|reply
http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
You still get to use git, except you push to a svn server (couple of the push pull commands are different but it works wonderfully).
[+] [-] paulasmuth|14 years ago|reply
https://github.com/cool-RR/GarlicSim/commits/master
[+] [-] cool-RR|14 years ago|reply
[+] [-] sscheper|14 years ago|reply
[+] [-] burgerbrain|14 years ago|reply
Git is also arguably more secure than many other VCSs since it (in a very very small and generalizing nutshell) works by creating a directed graph of SHA sums. You can't change a file and propagate those changes to other people without everyone being well aware of what has been done. Not unless you can compute useful code that collides with existing code... check out what linus has to say about that improbability some time^ ;).
No, security shouldn't be the issue for enterprise companies, though scalability is often cited as a potential issue. If you currently use perforce to a heavy degree, you might have some issues with going to git. This is not to say that git cannot work for very large companies, it probably just isn't going to work well if you put every project in your large company in a single one or two repos (as many companies do with perforce). It'll handle large projects fine however, it handles the linux kernel like a breeze.
^ http://osdir.com/ml/version-control.git/2005-06/msg00583.htm...
[+] [-] allad|14 years ago|reply