Sigh! Perhaps the enemy is the still surprisingly high number of programmers not using any source code control at all. Perhaps we should be working on educating those who still don't feel the need to use source code control on their own personal projects. But Subversion?
I just helped on a "major" project that worked remarkably successfully using good old CVS. I personally prefer Mercurial, and it's what I use for all but my smallest pieces of code, but did CVS work well for coordinating 50+ chip designers, software developers, document writers? Hell yes! Not even a single hiccup, no little thanks to a very helpful and standup IT guy. Good ol' CVS did the job just fine. Could newer technology be better? Yes perhaps I can think of a lot of hypotheticals where it would have been great to have a DVCS, but in practice, I can't think of all that many times where it would have made much of a difference. The fact that every one there, particularly the chip designers, knew how CVS worked, had worked with it for years, had their own work methodologies based on CVS, made the very thought of using anything else nothing but stupid.
Git is pretty awesome, I love using github. From what I've seen of Mercurial, it is also mostly blessed the same awesomeness.
Getting people to convert is a fairly big undertaking, though, and although the author touches on this, he might be underestimating the task of conversion a little bit.
The first of his 3 points (that git/mercurial's inferior handling of binary files is one of the major issues) is in my opinion dwarfed by an issue he doesn't even mention: git's cryptic user experience and sometimes insanely-scary (especially to git newbies) error messages. I've met plenty of coders who are brilliant programmers but are completely baffled by the very simplest of operations in git when they fail. I'm not sure a better user experience is even remotely on the radar of the folks who work on git, so for git newbies, it's back to svn.
Has anyone else noticed this?
I'd love to get my day job's project moved from svn to git, given the tremendous benefits (we experience a lot of pain when branching our svn repo), but the pain of moving has to be eased significantly. Moving a repo like ours doesn't just involve importing the repo, it involves training, dealing with all the errors and hangups, figuring out how to make our ancient installation Trac talk to our repo, connecting it to Eclipse and NetBeans, and adjusting all of our build processes. I think if the day to day git experience was less cryptic, we could probably handle the remaining issues.
Well, partially my personal ignorance with how that would work :) But also.. my team often has to break into pairs to work on sub-projects and new features, and it would be nice to have everyone on board rather than just a single person. The whole package is compelling. Thanks for the idea though.
You're welcome. git-svn is an interface to a svn server that handles the interaction with the svn server. You checkout from the svn server. Do local git stuff and then when you have a completed feature/bugfix you use git-svn to push it back to the svn server.
yes. the actively hostile UI of git is the only reason i can think of that makes a difference between hg and git. they are functionally identical (though hg is far better documented to boot). i've been screaming this from the mountain tops for years.
oh, and -another- aliasing system on top of bash's is just stupid, so don't even mention it.
The closer two things are to each other, the more they fight. Like the Hells Angels vs Bandidos, or the Bloods vs the Crips. I mean, coming as someone who is not involved in any crime, it would seem reasonable that the Hells Angels should battle the Crips, seeing as they totally represent different things. But no, they go fight the people closest to them.
What I'm trying to say is that Git is like the Hells Angels, Mercurial is like the Bandidos, and SVN is like the Crips. Microsoft Visual Source Safe is like MC Hammer.
I don't think MS ever did use VSS...from what I remember, they used a modified version of.....Mercurial?? Or maybe something else. Can someone else can be more specific?
I'll come right out and admit that I still use Subversion. And like it.
That seems like a crime to most people because I'm a Rails coder, but the truth is that I haven't had any need of anything else yet. I'm generally the only person working on my projects which means that Subversion meets all my needs.
I'm sure that there are benefits to converting, but every time I start the process I get turned off by having to learn a whole new way of doing things...
I'll second that - for 2 customers, we're just back to SVN, actually (despite I'm using Git for my own projects, because I like to commit offline, mostly).
The learning curve of Git is way too steep for non-technical participants in particular, at least in my experience, whereas they seem to handle SVN without much difficulties.
Sadly, yes. I run into them a lot, but always offline. The reason you don't hear about them is because the same people who don't know about DVCSes tend not to frequent forums like Hacker News and proggit. A lot of programmers--and I mean a lot--are just programming to make a buck. Some are good, some are bad, but at any rate, they're not in it for the craft of coding. They're in it because it's a job. Those people don't read the modern equivalent of trade mags because there's nothing in it for them. The only tools that matter are the ones they're actually using, right now. It's these people we really need to reach.
Hmm...do we? I mean, might the time to try and convince someone like that to switch to Git be better spent elsewhere, like trying to inspire the next generation of programmers who actually code because they love it?
I'm actually not surprised, and I've worked on plenty of client projects where the "workflow" was to login via FTP and edit live files on the server. If there was a chance for a potential conflict, just yell across the room to the other developer to make sure you don't step on each other.
Sadly, a few of these were for large interactive agencies. I try and steer clear of these kinds of jobs when I can, or at least try and push them towards svn or git.
I worked for a client that used this exact method, plus comments in the source to indicate who changed the code, with old code commented out. I was one of several developers working remotely. It was a mess.
When I suggested version control, the reply was "We're not big enough."
Yup, my employers are still standardised on CVS. We're hoping to start trying out SVN in the next year or so - but Git is just too different to gain any traction in the near future.
Not helped by the fact that SVN has hooks into the Visual Studio version control architecture, whereas Git has an odd plugin that works in a non-standard way.
You'd be surprised how many people still use RCS. I've recently learned RCS so I could make changes to files managed by Foswiki, a modern and quite nice Wiki.
Yep, my employer still uses CVS, and by "uses" I really mean blindly commits everything (including output files) using TortoiseCVS with no commit messages. No branches, almost no tags.
I mentioned git once to my boss and it was definitely over his head. So I put git (via Cygwin) on my machine and am using it with CVS (as much as I can).
Yeah, Subversion has always worked reasonably well for me. While I was in school at least, getting my project partners to use version control at all was a major victory.
With all the projects popping up on github I have a feeling I'll push one of my tinkering projects up there pretty quick.
"It’s easy, in the yin/yang of Hacker News and proggit, to forget that most developers are not even aware of what DVCSes are or what they do."
It's also easy, in the yin/yang (what?) of Hacker News and proggit, to forget that there's plenty of developers RIGHT HERE who do not grok DVCS. I sort of know what they are, and that they making branching suck less or something.
Hello, I'm nollidge, and I don't get DVCS. Where do I start?
Stick with it till you get past the learning curve.
Wait for the light bulb to go off.
There is really no better way to "get it". It will have some pain at first and you won't understand the benefits immediately but one day when you're coding and suddenly realize that you no longer weigh the pain and risks of creating a branch you'll suddenly wonder how you did without this tool for so long.
I started with http://monotone.ca/monotone.html#Concepts . Git and Mercurial took the same basic history structure and offer roughly the same abilities, but don't make such extensive use of certificates and have slightly different concepts of what a "branch" actually is and how branches relate to repositories and working copies.
For the sake of hopeful web-searchers FROM THE FUTURE, I eventually found http://hginit.com/ , which is an awesome intro to DVCS (specifically Mercurial).
For me, it was watching Linus' Google talk on git, and then reading some tutorials, and then just doing it.
Linus: http://www.youtube.com/watch?v=4XpnKHJAok8
GitReady: http://gitready.com/
Pro Git: http://progit.org/book/
A short little bit about git's internal model: http://eagain.net/articles/git-for-computer-scientists/
GitHub's Git Cheat Sheet: http://github.com/guides/git-cheat-sheet
A successful git branching model. gorgeous workflow and pictures. http://nvie.com/archives/323
Also, if you have any questions, feel free to email me. The only reason someone should be using SVN now is if there are institutional reasons or if you use lots of large binary files. I'd rather you send me an email about something that seems hard than give up and use an inferior tool. I'm not an absolute git master, but I've ended up explaining it to most of my classmates, so I've given that explanation a few times already.
No problem. It's something that's being worked on, just merging them becomes a pain. If your dependencies are truly static, in the sense that you're not modifying them or updating them often, it shouldn't be a big deal. Usually it's large images or other 'asset' type stuff that causes a bloated repo.
People are coming from a world where they see svn as being so much better than cvs (and source safe and what-not), but the only thing close to it in its class is p4, and they have to pay a lot for that, so it doesn't count.
Then someone convinces them that there's a better class of things and they want to give it a shot. git users talk about the power and wonders of git. hg users talk about how much easier it is to use than git. bzr jumps up and down slowly and says, "me too!"
In this sense, DVCSs are each other's enemies preventing our own adoption.
I've used hg a lot and I've been using git almost exclusively for a couple of years. A project whose source is in git is more likely to get contributions from me because it's just easier for me. Projects that use hg will get a contribution if it's a big enough pain because it means more work for me.
Odd, but as I was reading this I kept thinking of programming language flame wars:
> So why is there so much hating? I think what’s going on is that people are coming to these languages from Java or PHP, have their massive epiphany on how totally awesome these languages are, and then assume that only their language can have this level of awesome, so they begin evangelizing. The problem, of course, is that the other guy feels the same way, and is also evangelizing, so the Ruby and the Python guy end up in a locker-room-style temper-tantrum over whose language has the best frameworks or whatnot, instead of how much more awesome their languages are than the competition.
> This has to stop.
> Python’s enemy is not Ruby. Ruby’s enemy is not Python.
Poor Darcs, it's not even considered. I remember how awesome I thought Darcs was, but now we're almost done switching to Git. I would've stayed, but Git lapped Darcs on tools, performance, and stability. A shame.
I think it's a shame because Darcs has beautiful theory behind it and is written in my favorite programming language. I feel the same way about some hardware, like the SGI Octane with MIPS processors, dual board graphics cards, and a crossbar architecture. Practically speaking it's worthless because it pulls way too much power and even a cheap netbook is 10 times as fast, but it's still my favorite computer. So it's not a shame that there's a better product, it's a shame that the product I want to be the best isn't.
I've always had this issue with Mercurial - if you're actively developing and want to fetch updates from the upstream, you are forced to check in to your local repo, even if the code you're working on isn't ready to be checked in. Git might do a better job that mercurial with git stash, but mercurial's equivalent (hg shelve) sucks - when you unshelve, rather than generating typical conflict markers, it generates patch diff files, which are way harder to work with. When you're developing with a small team, this happens all the time. After a project wrestling with mercurial, my team forced me to switch back to SVN.
I tried using git (with git-svn) to work around this, and even with the easy-git porcelain, the learning curve (and cryptic errors) were ridiculous (basically, easy-git is a pretty leaky abstraction). There's absolutely no reason why a VCS should be that hard to use.
The problem is easily solved with smaller, more frequent commits.
In SVN, your changes had to be "ready to check in", which was this big, complicated ritual where you back up your changes, update, merge, check to see if the merge screwed with your changes, replace your backed up files, diff, unfuck the merge, and finally, commit.
With DVCSs, there's no reason not to commit partially done features. If you're at enough of a stopping point to want to merge in other people's changes, you're at enough of a stopping point to commit what you have so far. Your code only needs to be "ready" when you push it out.
I'm sorry, but this last point simply isn't true. Sometimes I'll be building a new feature, and I'll expose a bug which another dev will fix and check in, or another dev will add some hooks for me. The new feature definitely isn't ready to check-in, but I need to get their changes to continue.
That's my point, this "ready" concept is just a holdover from SVN. There's no reason a commit has to be "ready" in any way. You can even say that in the commit message.
I agree with that. However, if you been making intermediate checkins, it's more difficult to cherry-pick changes to push upstream. Especially if you've been doing lots of intermediate checkins - it's easy to forget which changes were intended to be real (as opposed to dummy code you've put in for testing, etc), and push selectively.
Maybe this is easier in Git, but it has the worst interface I've ever seen, and that's saying a lot.
If you're considering cherry-picking, you're still thinking in an SVN mindset. We did the exact same thing for a while before figuring it out, with some help from a few people who had used DVCS longer. You just have to use it for a while and you'll start to see the workflow where this isn't a problem.
We used mercurial for almost a year before the team rebelled and forced a switch back to SVN. :) It was all of our first experience with a DVCS.
It's not just cherry picking - if you've spread changes across multiple commits, it's much more difficult to manage them. Yes, you can diff cross revisions. But that's more awkward. Worse - if you commit so you can merge in changes from the mainline, all of your changes get lumped together - which may be logically different fixes - and some may even be debugging code that definitely shouldn't end up in the mainline. If you later need to push a subset of your changes, you're in for a world of hurt.
I guess if you get people to use patch queues religiously, you can work around this. But patch queues (in mercurial at least) are definitely rough around the edges, and have their own share of problems.
I'm guessing this process is better in Git. But if I can't deal with the interface, there's no way I'm going to convince the rest of the team to do so.
If people have suggestions on how to deal with this kind of stuff, I'd love to hear people's suggestions. My HN username @ gmail.
To finish the thought, you only have to commit to your local repo. No one has to see the unfinished code. The only place where this would cause a problem is where you want to roll back only to 'good' commits. Git, at least, lets you merge commits and erase 'unfinished' commits.
btw, if you just run 'git fetch', it will just grab any new commits - it won't modify your working directory or try to merge automatically. i believe 'hg pull' is the same - it just gets the new heads, it doesn't try to merge. you shouldn't need to stash/shelve just to get the new work.
Yes, but what use to you are the newer commits unless you bring them into your working directory? Typically you're doing this to get some code to help enable the feature you're working on.
You can get around this some of the time with hg pull; hg up (instead of hg fetch). This works as long as you don't have a conflict. If you have a conflict you have to check in and merge at that point.
I do agree that git stash is superior to the hg alternatives.
Yes - but sometimes there are conflicts. Often they're totally trivial - but it's very strange that my workflow gets altered - forcing me to checkin unfinished work - based on whether or not some other programmer's change happens to conflict with what I'm working on.
His point about binary files is true. Until it gets as good as SVN at handling binary files then it probably will not have an easy time getting people to convert.
How likely is it that Linus will add better support for binary files from an outside project or do we just have to use the forked git?
Actually, it's not really that bad. The problem was that with Git or Hg, when you fetch you get every version of every file for the whole history of the project. Which means if you've had a lot of big files, you get ALL of them. Also, they don't delta compress well, so that can be a lot, much of which you may never need again, so it's inefficient. For most projects, this isn't a big deal, but if you have a bunch of large texture files or video that MUST be in the project (game development, perhaps), this can be an issue.
Subversion is "better" at this only because it does shallow checkouts - it only gets the last version of the project. It is still ludicrously inefficient in it's transfer protocol.
Git can actually do this type of development fine - if you do 'git clone --depth=1 [url]' it will also do a shallow clone (just the last commit and it's associated content) and will transfer the data much more efficiently than SVN. In the past you couldn't then commit to that repo, which was the issue, but in newer versions you can. You can also later deepen the repository if you want. It is not an often used feature, but I think it brings Git pretty close to on-par with SVN for large projects, if not better in many respects.
"In the past you couldn't then commit to that repo, which was the issue, but in newer versions you can."
You cannot do this as of Git 1.6.6, according to the documentation, which states:
"A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches."
It's part of their nature. They store the complete history of the repository by default on your computer. Git does not pack the files by default. I am still figuring out all the innards of Git but I believe that it stores a new copy of the file each time it changes and then hardlinks the tree object to the new file. you can run a pack operation that will create deltas of the files but this is an additional step. Any Git gurus here please correct my understanding of how Git manages binary files.
His point about binary files is true. Until it gets as good as SVN at handling binary files then it probably will not have an easy time getting people to convert.
I don't think I've ever stored a binary file in my source-code control system. (Hint: your VCS is not your backup server.)
(Yes, OK, I have a favicon.ico in some of my repositories. This has not detracted from the "git experience".)
Of course it's not a backup solution. That's what timemachine, superduper, mozy are for. Let's pretend that you are a graphic artist and you have a psd file with a picture for your website. You make a change that does not work well and your undo history is past it's limit. Instead of having to copy the file, rename it, make changes, and clutter up the folder you have one file with a history and commit messages that tell you what you changed. A commit message of "made the background transparent" followed by another commit "changed the font color to orange" is a lot better to see than a file name of "project_trans_back_orange_v1.psd" To each their own though.
A version control system is such that it can handle versions of the project and not just versions of the source code.
FWIW: I keep whatever files in the project I have uncompressed in git and it hasn't killed my HD space yet.
Let's pretend that you are a graphic artist and you have a psd file with a picture for your website. You make a change that does not work well and your undo history is past it's limit. Instead of having to copy the file, rename it, make changes, and clutter up the folder you have one file with a history and commit messages that tell you what you changed. A commit message of "made the background transparent" followed by another commit "changed the font color to orange" is a lot better to see than a file name of "project_trans_back_orange_v1.psd"
Of course, if Photoshop were Free Software, then you could just make the undo history and the git repository the same thing. That would be the ideal situation.
That would be amazingly powerful. I remember reading something about how convoluted the psd format is because of the backwards compatibility along side new features so I don't know how easy that would be for psd's.
I don't think I've ever stored a binary file in my source-code control system. (Hint: your VCS is not your backup server.)
I do small-scale game development (Flash and iPhone) with a team of 2-3. We've always committed image, audio and animation binary files to source control (currently Subversion) so we can track changes, just as we do for code. To be honest, I can't imagine what other approach we should be taking.
Turn 100 developers loose and amazing things happen to your "source code" repository. I used to find entire images of Microsoft CDs in ours. The developers wanted to be able to get to known state for compiling, Visual Studio and anything else they were using went in to CVS, and later subversion. Then because they had so much trouble with different versions of the Visual tools making different output they started checking in all the built DLLs and executables.
The developers should have been soundly thrashed with a cane, but if it is possible to check in a binary. They will do it.
If you want to reliably maintain (or even build) a given version of the code, it's the right thing to check in the versions of the compilers and build tools that are known to work. A good tool is small, fast, meant to be run non-interactively, and takes instructions in an easily-reviewed file. Making your official build in Visual Studio is a bad idea for all these reasons--even Microsoft doesn't do that, at least when I contracted there. (They used a make clone with some extra support for metadata from win32 binaries.)
I don't think I've ever stored a binary file in my source-code control system. (Hint: your VCS is not your backup server.)
Backup is not the point. The point is that you should be able to get onto a new machine, and execute your build process, and it should work. If some of the application files are missing, it wont.
I have a favicon.ico in some of my repositories.
It seems that all you're really saying is that your applications aren't media-intensive (binary files limited to an icon), and you don't want to think about ones that are.
Mercurial’s enemy is not Git. Git’s enemy is not Mercurial.
Their enemy is Subversion.
.. most developers are not even aware of what DVCSes are or what they do. .. The goal right now, if you honestly believe that the DVCS workflow is better—and I do—should be to get the mindset out there, to make more people aware of what DVCSes have to offer and why they should be using them. </quote>
Sigh! Perhaps the enemy is the still surprisingly high number of programmers not using any source code control at all. Perhaps we should be working on educating those who still don't feel the need to use source code control on their own personal projects. But Subversion?
I just helped on a "major" project that worked remarkably successfully using good old CVS. I personally prefer Mercurial, and it's what I use for all but my smallest pieces of code, but did CVS work well for coordinating 50+ chip designers, software developers, document writers? Hell yes! Not even a single hiccup, no little thanks to a very helpful and standup IT guy. Good ol' CVS did the job just fine. Could newer technology be better? Yes perhaps I can think of a lot of hypotheticals where it would have been great to have a DVCS, but in practice, I can't think of all that many times where it would have made much of a difference. The fact that every one there, particularly the chip designers, knew how CVS worked, had worked with it for years, had their own work methodologies based on CVS, made the very thought of using anything else nothing but stupid.