I adopted mercurial when git was "painful" to use. It seems as though this has changed, but I see no compelling reason to switch just because all the Rails kids think git's cool right now.
I'm trying very hard to like git, being a Rails kid coming from the svn world. Still, besides the kickass merging, everything else seems ass-backwards.
Remote work especially is bonkers. Push/pull? Easy. Add/Delete remote branch? Off to google for me...
i'd like to know why people are using what they are. did you pick git because you just recently started using version control or was there really something you needed in it that made you switch?
i've been using cvs for about 10 years now and have no reason to switch to anything else. it does what i need without any extra fluff, all my projects are in cvs, and the majority of the projects i contribute to use cvs.
We were using svn for a while, but micromanaging the individual files turned out to be too tedious for me to introduce to our group.
git add .
git commit -a
yes, it's two commands but in return git will automatically find new files, internally delete files you have deleted, and even automatically find renamed files (under most conditions).
I don't have a great argument about why we chose git over mercurial, it seemed like the right choice. But I can tell you that git is a lot better than svn for our purposes.
I find it somewhat funny about the complaints of git being difficult to use. Personally, our team found svn difficult to use due to having to micromanage moves adds and deletes.
edit: also, not having a bunch of .svn directories peppered all over your directory structure is nice, just one .git directory at the top. You can move directories in and out from other locations without worrying about anything.
I introduced Bazaar at my new research lab, with good results. Our requirements were:
1. They're scientists who need to do some programming, rather than programmers who need to do some science, so the command line is acceptable but confusion and complexity are not.
2. Remote hosting is not kosher. Dunno, there are rules, apparently there was a bad experience once and the NIH got involved.
3. Everyone has their own work to track, but project ownership can be fluid. Another guy should be able to seamlessly take over one of my projects without losing the history, and with 30 seconds or less of over-the-shoulder explanation on how to do it. If an operation requires significant manpage investigation, they'll probably get impatient and just use scp.
4. None of the machines is expected to be on all the time. The network will almost always be available, but we all have laptops, too, so offline work ought to be possible.
5. Speed isn't a big issue; our machines are suave and everything's on a LAN.
Subversion would be OK if we had a designated server that's always on. But we don't. Git has the low-level design figured out a little better than Bazaar, but the plumbing commands are confusing and I couldn't figure out how to make a shared repository temporarily act like it's all centralized, and I worry that a Windows user might come in and spoil the party.
As far as features go, git, hg, bzr and darcs borrow from each other like crazy; the differences are mainly in developer priorities and culture. Bazaar's team cares about documentation and usability above all else, which is what I care about too, here, so that's what I went with.
Using mercurial -- it and git seem significantly better than the rest, but when I recently test-rode them both, mercurial felt like it worked better cross-platform, and the overall design felt cleaner. Git would be my second choice, and I'm sure github and the network effect will do a lot to popularize it.
(I've read several blog posts in which people try git and are absolutely thrilled, but in almost all cases they were previously using CVS or SVN.)
FWIW, I had been using Monotone for a while, but mercurial seems quite a bit simpler in day to day use.
I use a combination of git and Subversion. SVN for the main repo that is shared between developers (with many developers working at once the lack of atomic commits really sucks), and git as my own offline versioning system. The code that I write tends to go through several iterations, and I'm loathe to commit anything to SVN until things work well enough to please me. Bad code should never make it into your prod repo, but I'm not a fan of rewriting/deleting mass chunks of code without SCM to back me up.
I switched from CVS to SVN because I needed to rename a bunch of directories, and that's so incredibly painful in CVS that I might as well start a new repository.
I switched from SVN to git because I needed to work offline for a week, so I gave git a try (initially, I had my project versioned under both systems) and liked it so much I stuck with it.
Using bzr: our development is done in Python, so it's handy to be able to a) modify things if we need to and b) bundle bzr with our company's python install.
It was the first distributed VCS I have used. I highly suggest it for personal or small projects, as it supports "dumb storage" and thus you can host a repo anywhere you have ftp or sftp access. It is also handy for working around annoying firewall restrictions where you can't really checkout code the way a centralized system does.
git because I was able to introduce it gradually, due to its great svn integration. We just switched to it fully last week.
I love DVCS because I get to keep the code on my computer version-controlled, and the power of branching, merging, and cherry-picking is awesome once you get used to it.
For new projects I'm using git rather than subversion. I normally develop on my desktop system, but when I'm on the go I use my laptop. Subversion isn't useful for that kind of scenario if you don't have constant internet/network access. With git I can do commits, look at the history, etc. even when I'm on my laptop and offline. (you can keep copying the whole repository with svn but that pretty much defeats its purpose)
I'm pretty new to git though, and I haven't even touched the more advanced features.
using subversion over cvs because of repository revision numbers, renaming of files.
using git over subversion because of sane branching / merging / rolling back, history tracking, SPEED, increased redundancy (everybody is backing up the repo!) and local commits.
All projects right now use Subversion except one new project at home that I decided to try Git out with.
All projects at work though use Subversion for now, but I am the only developer. (Just makes it easy to revert incase of issues as our system deals with a lot of numbers)
I use git because the low-level design is rock-solid and simple enough for me to understand. I also like distributed version control for the work alone and on a team aspect.
This does not mean git is easy to use or that I'm even very good at it, BTW.
If you find your self with directories like "v1" "oldv1" "updateD!!!" you need version control :). Subversion has GUI clients integrated into file explorers so you don't even notice the overhead.
I wrote more about it here, if you'd like convincing:
It's not. I spent a week setting up and learning to checkout, update, add files, and commit. The only workflow change is an occasional trip to the shell to commit, but this is usually at the very tail of a session where it doesn't break flow anyway.
Then (if you put in on a public server, of course) your work is accessible from anywhere. Run into a friend at Starbucks and want to show him the module you wrote today? Just get into the shell and checkout your repository.
Not only that, it's a perfect record of your project. Occasionally I need to assess the status of the project vis-a-vis some point in the past (for myself when strategizing, for my boss when he needs a report, etc). Being able to look at the commit logs saves time and produces better reports (commit logs don't forget).
So even if you use only the most basic features, you still get an immense benefit from using a VCS. And the hours it's saved me in trivial tasks made it well worth the week it took to hammer down.
I have this feeling too. However, I've just started using git, and one nice thing is the sense of closure when you "commit" something, it's a milestone, a bit like a release. It's also nice to have a log of changes, with a short comment about each one.
But I haven't had any actual advantage from it so far; and any nervousness about playing around with files has shifted across to nervousness about playing around with the repository (I had to delete it and start again a couple of times). Actually, I find doing anything to the repository (reverting, branching etc) terrifying, because I don't really understand what it's going to do, and I could lose everything. If only there was a way to back it all up first... ;-) I'd rather just get on with my actual tasks! Just my experience - so far.
I use Subversion, and constantly check in my code. I love the feeling of control and permanence. 10 source files soon becomes 30, and 10 versions soon becomes 100 => Yes.
How often do you do a bigger change, then realize you still need some pieces of the previous version? Version diff to the rescue!
Currently on SVN switching to git soon, just don't have the time at the moment. git looks like the best choice, and if I was starting anything new I would start with git now.
Using bzr. A few months ago when evaluating bzr, git, and mercurial, the features were similar between all three, but bazaar won in the ease of use category.
GitHub is just awesome, especially for open source projects. (of course I say this just as GitHub goes down for the first extended period of time since I started using it)
I know from experience that git is superior, but I still use svn because it is the (modern) Lingua Franca of revision control. TortoiseSVN on Windows also gives it a definite advantage on that platform.
Can anyone with experience with both SVN and Git comment on the pros/cons of branching and merging (this is something I do often in Perforce). Which would you use based on this one issue?
Sorry! I follow HN primarily through the RSS feed and a lot of posts/threads never show up there.
Before posting, I did Google for polls on the subject of version control and didn't turn up anything (oddly enough, this thread seems to be at the top of the results page):
Even if I had seen your poll, though, I probably would have posted anyway because I'm interested in getting a feel for how many people use some of the systems that are listed at top besides Git, Mercurial, and Subversion.
[+] [-] apgwoz|17 years ago|reply
[+] [-] KirinDave|17 years ago|reply
I wouldn't use git if it didn't have cheap inline local branching. It is the Killer Feature.
[+] [-] jrockway|17 years ago|reply
A stopped clock is right twice a day.
[+] [-] jmtulloss|17 years ago|reply
[+] [-] MicahWedemeyer|17 years ago|reply
Remote work especially is bonkers. Push/pull? Easy. Add/Delete remote branch? Off to google for me...
[+] [-] vito|17 years ago|reply
[+] [-] cookiecaper|17 years ago|reply
[+] [-] jmtulloss|17 years ago|reply
[+] [-] ph0rque|17 years ago|reply
[+] [-] there|17 years ago|reply
i've been using cvs for about 10 years now and have no reason to switch to anything else. it does what i need without any extra fluff, all my projects are in cvs, and the majority of the projects i contribute to use cvs.
[+] [-] eggnet|17 years ago|reply
git add .
git commit -a
yes, it's two commands but in return git will automatically find new files, internally delete files you have deleted, and even automatically find renamed files (under most conditions).
I don't have a great argument about why we chose git over mercurial, it seemed like the right choice. But I can tell you that git is a lot better than svn for our purposes.
I find it somewhat funny about the complaints of git being difficult to use. Personally, our team found svn difficult to use due to having to micromanage moves adds and deletes.
edit: also, not having a bunch of .svn directories peppered all over your directory structure is nice, just one .git directory at the top. You can move directories in and out from other locations without worrying about anything.
[+] [-] etal|17 years ago|reply
1. They're scientists who need to do some programming, rather than programmers who need to do some science, so the command line is acceptable but confusion and complexity are not.
2. Remote hosting is not kosher. Dunno, there are rules, apparently there was a bad experience once and the NIH got involved.
3. Everyone has their own work to track, but project ownership can be fluid. Another guy should be able to seamlessly take over one of my projects without losing the history, and with 30 seconds or less of over-the-shoulder explanation on how to do it. If an operation requires significant manpage investigation, they'll probably get impatient and just use scp.
4. None of the machines is expected to be on all the time. The network will almost always be available, but we all have laptops, too, so offline work ought to be possible.
5. Speed isn't a big issue; our machines are suave and everything's on a LAN.
Subversion would be OK if we had a designated server that's always on. But we don't. Git has the low-level design figured out a little better than Bazaar, but the plumbing commands are confusing and I couldn't figure out how to make a shared repository temporarily act like it's all centralized, and I worry that a Windows user might come in and spoil the party.
As far as features go, git, hg, bzr and darcs borrow from each other like crazy; the differences are mainly in developer priorities and culture. Bazaar's team cares about documentation and usability above all else, which is what I care about too, here, so that's what I went with.
[+] [-] silentbicycle|17 years ago|reply
(I've read several blog posts in which people try git and are absolutely thrilled, but in almost all cases they were previously using CVS or SVN.)
FWIW, I had been using Monotone for a while, but mercurial seems quite a bit simpler in day to day use.
[+] [-] potatolicious|17 years ago|reply
[+] [-] nostrademons|17 years ago|reply
I switched from SVN to git because I needed to work offline for a week, so I gave git a try (initially, I had my project versioned under both systems) and liked it so much I stuck with it.
[+] [-] nihilocrat|17 years ago|reply
It was the first distributed VCS I have used. I highly suggest it for personal or small projects, as it supports "dumb storage" and thus you can host a repo anywhere you have ftp or sftp access. It is also handy for working around annoying firewall restrictions where you can't really checkout code the way a centralized system does.
[+] [-] llimllib|17 years ago|reply
I love DVCS because I get to keep the code on my computer version-controlled, and the power of branching, merging, and cherry-picking is awesome once you get used to it.
[+] [-] pmjordan|17 years ago|reply
I'm pretty new to git though, and I haven't even touched the more advanced features.
[+] [-] elai|17 years ago|reply
[+] [-] aaronblohowiak|17 years ago|reply
using git over subversion because of sane branching / merging / rolling back, history tracking, SPEED, increased redundancy (everybody is backing up the repo!) and local commits.
[+] [-] mihasya|17 years ago|reply
[+] [-] truebosko|17 years ago|reply
All projects at work though use Subversion for now, but I am the only developer. (Just makes it easy to revert incase of issues as our system deals with a lot of numbers)
I like Git .. it's very fast and simple to use :)
[+] [-] bestes|17 years ago|reply
[+] [-] ced|17 years ago|reply
[+] [-] eru|17 years ago|reply
[+] [-] kalid|17 years ago|reply
I wrote more about it here, if you'd like convincing:
http://betterexplained.com/articles/a-visual-guide-to-versio...
[+] [-] joestrickler|17 years ago|reply
Then (if you put in on a public server, of course) your work is accessible from anywhere. Run into a friend at Starbucks and want to show him the module you wrote today? Just get into the shell and checkout your repository.
Not only that, it's a perfect record of your project. Occasionally I need to assess the status of the project vis-a-vis some point in the past (for myself when strategizing, for my boss when he needs a report, etc). Being able to look at the commit logs saves time and produces better reports (commit logs don't forget).
So even if you use only the most basic features, you still get an immense benefit from using a VCS. And the hours it's saved me in trivial tasks made it well worth the week it took to hammer down.
[+] [-] 13ren|17 years ago|reply
But I haven't had any actual advantage from it so far; and any nervousness about playing around with files has shifted across to nervousness about playing around with the repository (I had to delete it and start again a couple of times). Actually, I find doing anything to the repository (reverting, branching etc) terrifying, because I don't really understand what it's going to do, and I could lose everything. If only there was a way to back it all up first... ;-) I'd rather just get on with my actual tasks! Just my experience - so far.
[+] [-] mihasya|17 years ago|reply
[+] [-] schtog|17 years ago|reply
I feel like I need something sometimes but most of the tools above seem a bit complicated and not very intuitive.
[+] [-] asmosoinio|17 years ago|reply
How often do you do a bigger change, then realize you still need some pieces of the previous version? Version diff to the rescue!
[+] [-] wastedbrains|17 years ago|reply
[+] [-] mcargian|17 years ago|reply
[+] [-] tlrobinson|17 years ago|reply
GitHub is just awesome, especially for open source projects. (of course I say this just as GitHub goes down for the first extended period of time since I started using it)
"git bisect run" is incredibly cool for tracking down when a bug was introduced: http://tlrobinson.net/blog/?p=51
[+] [-] silentbicycle|17 years ago|reply
[+] [-] hapless|17 years ago|reply
Distributed version control just doesn't get simpler.
Unfortunately, it's not particularly portable and it's not particularly fast. The former I can blame on its dependence on ghc. The latter, I dare not.
[+] [-] Prrometheus|17 years ago|reply
[+] [-] jsmcgd|17 years ago|reply
You or may not find it helpful. Hope you do.
http://changelog.complete.org/posts/698-If-Version-Control-S...
[+] [-] eru|17 years ago|reply
[+] [-] jcromartie|17 years ago|reply
[+] [-] silentbicycle|17 years ago|reply
[+] [-] timtrueman|17 years ago|reply
[+] [-] llimllib|17 years ago|reply
[+] [-] rsobers|17 years ago|reply
[+] [-] barryfandango|17 years ago|reply
[+] [-] johnm|17 years ago|reply
[+] [-] graywh|17 years ago|reply
[+] [-] wtrk|17 years ago|reply
Before posting, I did Google for polls on the subject of version control and didn't turn up anything (oddly enough, this thread seems to be at the top of the results page):
http://www.google.com/search?hl=en&q="version+control"+poll+site:news.ycombinator.com
Even if I had seen your poll, though, I probably would have posted anyway because I'm interested in getting a feel for how many people use some of the systems that are listed at top besides Git, Mercurial, and Subversion.
[+] [-] ulysses|17 years ago|reply
For that matter, this one doesn't have plain old RCS, which is what I use.