Monday, January 2. 2012Perils of not switching to Git
Somebody probably already recommended you to switch to Git, because it's the best VCS. I'd like to go a step further now and talk about the risk you're taking if you won't switch soon.
By still using SVN (if you're using CVS you're doomed anyway), you communicate the following:
Be aware that good developers today will not consider working with or for you if you're still using SVN. - And that's the risk. Until recently I thought that Mercurial would be an acceptable alternative to Git. Until I used mercurial for some time. It is not. Update: The comments are not too approving, to say the least. Lets see what time will tell. In the meanwhile I'll attach links to this blogpost: Trackbacks
No Trackbacks
Comments
You are kidding right?
Not everyone has the same workflow and not every team needs the same tools. Not using every new technology that comes up does not make you ignorant. Developers who do not work with you just because you are "still" using Subversion, are probably ... dunno ... misguided? Well, feel free to pity everyone not using Git.
I must totally protest your derogative comments about CVS, which is a version control system that does, in contrast to svn, have its uses still.
Also, some people benefit from having a non-distributed VCS, however weird this may look to you. As for workflows, I agree with I.C.Wiener on that. New technologies may be good. They may be bad. They usually have good and bad parts. They may be over-hyped, which is actually dangerous. Blind zealots are dangerous (and often ridiculous; I remember your posting about how you defended PHP for years and now “know better” – what will you say about git in a decade? maybe you’ll know better and use CVS 1.14 then…) so, please.
Forgot to check reality didn't you?
SVN is by no means a bad version control system. It's different, but not worse. Both systems have their strengths and weaknesses. In git I totally dislike how it can be configured to transparently convert end of line characters. Like that you can never be sure how the files arrive on a client pc. Wonderful headaches for systems that e.g. rely on hash values. In git I appreciate how fetching repo changes doesn't automatically imply merging your current work with those changes. In SVN I don't like how it unnecessarily can slow you down in presence of slow network connections. Some strengths of SVN I've come to appreciate are its ability to do partial checkouts and its management of externals.
Sigh. Git is great software, but many good developers legitimately don't care about the advantages over subversion and calling them ignorant is not going to change their minds. Also, if you are a bad developer, switching to git isn't going to solve your problems, in fact it could well make your problems worse if you don't understand how to use it properly.
Our project's consideration to still use SVN up till now has been to keep the barrier of entry for relatively novice (non-floss-seasoned) contributers low. That's of course a tradeoff, but I think a valid one.
In my company we still use SVN. At least some developers would like to switch to git, but
1. We do not want to use more than one VC system at a time, using git would mean say good-bye to SVN 2. Non-developers work on Windows using TortoiseSVN, and it seems TortoiseGit is not yet as mature as TortoiseSVN 3. The Trac integration with git is not yet as mature as with SVN, esp. squeezes Trac 0.11 (trac-git even has been removed from testing, because of incompatibility with wheezys Trac 0.12) 4. Our CI tool (bitten) does not support git in the current version, AFAIK Which means, that we will not switch from SVN to git any time soon.
So, if back in 2008 you were using SVN or CVS with no major troubles you were OK but now in 2011 (sorry, 2012) if you are still using SVN (with no major troubles) in your development processes you are an asshole ?
Sorry but this is stupid and all of your assertions are invalids ; I'll hate working with someone like you ! Migration from a CVS to a DCSV means lot of time and money for a company which maintains dozen and dozen of systems more or less actives. If it's just for the hype and without strong and clear benefits, this is a bad move.
I've got to defend mercurial. Git seems to take pride in adding more and more bizarre and arcane features with bizarre and arcane behaviour. It's also full of weird "shortcuts" that I feel strongly encourage a particular working style - which is strange for a tool that's supposed to be "more flexible".
Everything makes so much more sense in mercurial. But I have to agree that anyone still using a centralized VCS is a dinosaur. "Migration from a CVS to a DCSV means lot of time and money for a company which maintains dozen and dozen of systems more or less actives." Heh well you see that's just the thing - most DVCSs don't really need any "administration". If you want to set up a repository server (you don't have to at all) it's pretty simple & straightforward.
Robert wrote:
> most DVCSs don't really need any "administration" Totally wrong. Think of a company. Surely you want to control access to your $VCS. Now you already have kerberos in place for instance. Try to make gitolite work with kerberos instead of ssh keys. Impossible? Wrong tool then. By the way: svn over http solves this task.
I’ve added Kerberos to the CVS package in Debian by popular request both in the BTS and LP. If you want to test it, be my guest
git is a tool. It isn't getting better by you making it a religion. Your arguments are moot. Almost everyone uses Windows. Do you use Windows? Also git isn't very good at cooking potatoes. It is a tool for a specific job. Without mentioning the job the term "best" is pointless. So how would you check out a subdirectory of a git repository without downloading all the stuff you don't need? How would you fork a single file while sticking the rest on master? Impossible? Then git is not the right tool for the mentioned tasks. By the way: CVS solves them.
This git vs $VCS war reminds me of emacs vs vi. I should probably stop feeding the troll now.
It would do you well if you'd actually know a little about the tools you're speaking of (mercurial, particularly).
I love the way how most commentators take the bate.
 Although I agree that the parameters under which the assumptions in this blog post have not all be explicitly defined, the fact remains that the point mentioned are not about what is real but how things are *perceived*. I wouldn't go as far as to say that good developers today will not consider working with or for you if you're still using SVN (as mentioned a tool is just a tool). However, the best devs I know will certainly frown upon the lame reasons usually given for not switching to something that would make their lives easier. Obviously not everybody's workflow is the same, but if you really care about attracting the best developers to your company you will have to give them the freedom to work from other locations then just the desk you assign them to. And that is a hell of a lot harder to do with a centralized distributing system. I agree that SVN is by no means a bad version control system (I'll not comment on Mercurial) it just not generating the buzz and momentum Git is. Again: As a lot of other things in modern society it's not about what is real but how things are *perceived*.
Hey, we use SVN internally - it works beautifully. Now one external development team decided they want to use git - next time I will veto such a request. They don't get the fact, that they need to push changes to the central repository (yes we only pay what we see...) and the tools suck on our primary development plattform (windows, and no I have no option to switch). Ok - they also failed to setup the central server in a sane way.
So to make the long story short: Yes git might be a good tool, but for our corparate needs I will always vote for the established technology. |
