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.
> Mercurial's metaphor for local branching is awkward.
That may be true (honestly, I don't know), but I haven't yet needed to maintain different branches of projects I'm working on and so it's a non-issue at this point. If at some point it becomes an issue, and I find Mercurial lacking, then of course I'll take a closer look at git, who probably does it more appropriately.
Mercurial also has cheap local branching, though to my understanding it is easier to close out branches that have been merged back in / abandoned on git. The mercurial developers are working on this, though.
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...
Under what OS, hardware platform, filesystem, project size, etc.?
Not knee-jerk arguing, genuinely curious. When I compared them on Windows and OpenBSD, I never had a speed difference of more than about 5% (not counting git db repacking), even with a project that had 40,000+ commits, 10+ very active branches, and about 2 GB of code + data.
Admittedly it was probably either the environment or the remote server causing the problem. I was running it under Cygwin on Vista, and it was a fairly huge project. I was running git under the same environment for the same thing (with a different remote origin), and even then I noticed git was much more snappy.
It's nowhere near an actual analysis, just my experience in my limited use (and probably influenced quite a bit by things that I've heard).
The point of a large repository isn't whether or not you can store it. The point of a large repository is that it takes a long time to clone, and cloning is pretty damn important in a DVCS.
I don't think anybody would suggest that size of repository matters for the number of bytes involved. There are obvious side effects of a large repository.
there is a mingw port for windows. untested by me, but it looks credible. as for os x, that's all i use, and git works PAINLESSLY on it. i'm not sure where you got this information from.
Git works on OS X and Windows, but it isn't quite as fast (many of its speed optimizations are coupled with aspects of the Linux filesystem), and its maintainers are placing low priority on portability. I never said it didn't work, just that it isn't especially important to them. That raises a lot of red flags for me.
I work on amd64/i386/sparc OpenBSD at home and Windows at work, and I think version control systems are one of the tools that should be especially platform-independent: How will you port your project to another platform if you can't even track patches for it there?
I'm not saying that it doesn't work, just noting that so you can make an informed decision based on your priorities. I hear a lot of buzz about Git, but hardly anybody mentions this, and changing VC systems with thousands of commits can be extremely painful.
Where Git is written in a mix of C and sh scripts* , Mercurial is written in Python (except for a few parts written in C for speed, such as its diff algorithm), and its design seems far less coupled with any particular platform (and much cleaner overall, IMHO). I spent an afternoon importing a very large project (40,000+ commits, 10+ branches) currently using perforce into monotone, git, and mercurial repositories, and compared them. (This was on Windows.) The git interface seemed in many ways too rough around the edges to me, and while it was very nearly as fast as mercurial (and a bit faster than mtn, even with cached inodes), the database also needed to be re-compacted. Mercurial was much, much more straightforward to use than either mtn or git.
OK, I know you're probably not reading this anymore, but I'll give it a shot :-)
Could you give me a reference to "git is not quite as fast on OS X" because I certainly haven't noticed it. On windows I could feel how slow it was, but not on OS X.
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.
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.
Ok, this convinced me to at least give git a try. I made the move to SVN from CVS years ago to be able to rename / move stuff in the repo, but the offline version control would keep me from keeping a bunch of updates in a branch uncommitted while I do a major push.
My current offline version control system has been leaving all the files open in TextMate to take advantage of undo/redo. (Horrible I know).
If you just want the offline aspect, you can use svk (http://svk.bestpractical.com/view/HomePage). I also switched to git for that (and stayed because I liked it better in a lot of other respects), but I found out afterwards that you can use svk to use svn offline.
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.
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 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.
No. Whenever I go on a tangent, I just make a copy.
I do AI, maybe that's the difference. Honestly, apart from utils.lisp, I wouldn't cry much if I suddenly lost all my files. Code is trivial, the important point is in the experience / insights.
I'll try it some day for sure. It's just not that appealing. It was the same with Emacs.
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.
And I like how bzr is willing to act like svn on demand. Setting up a shared repository is easy, other users can pretend they're using a centralized VCS as long as they need to, and when you eventually encounter a situation where distributed development would work better, not much really needs to change -- it's version control with no regrets.
I imagine learning git would probably be much easier if you were already familiar with bzr, since you'd already have a point of reference for most of the operations. The same way C is easier to structure if you already know a higher-level language like Python -- the abstract concepts are already familiar, so it's just a matter of translating them to another language, rather than figuring it all out from scratch in a pricklier environment.
" 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."
Like many things in the software world, the more you know, the better off you are!
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?
svn as of 1.5.0 does support merge tracking. I must admit that when first looking into svn I was very surprised to find that it did not originally support it.
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.
actually, i've not found it to be difficult to use, just not as slick, clean and intuitive as other options. not the best, but not exactly bad, per se.
Multiple daily backups produced by rsync using hardlinks works well when revisions are too drastic and frequent to give a meaningful history. version control will just get in the way of one or two people drastically refactoring a young project.
I have to respectfully disagree here. Having super-lightweight branching and local commits has helped me greatly, even in the tumultuous early days of a new project. Basically, it gives me the freedom to create a branch, hack for a while, and then either pull the changes into the trunk or abandon them, while still keeping an easy "bookmark" in place (a.k.a. the branch itself) to go back and review later.
Using rsync may offer a history of your code, but without any associated semantics, you're dependent on your own memory and grep to actually find out why a change was made. Making commits intentional, and associating them with a particular task, will greatly simplify your code archeology later. Rest assured, some day you will need to figure out why certain decisions were made, and your memory won't be complete (if it was even you who made the decision the first time).
Furthermore, adding a ticketing system from day 1 really helps impose a useful type of discipline onto your process. Work to be done is described in a ticket, and the ticket identifier gets referenced in your commit messages. Much like basic version control discipline, having a record that associates change requests with units of work will help keep you sane down the road.
I'm not arguing with the value of a filesystem as a general-purpose organizational tool. However, it's a strictly weaker tool in terms of structure and semantics than a proper VCS. Also, not only does using a raw filesystem put the burden on you to remember the associations between branches and versions, it also gives you zero support for merging once those branches are made.
Git is pretty good about following renames, moves, and other changes to the underlying filesystem, while still maintaining a proper graph structure to relate revisions to each other. Fast network replication and mirroring is just another benefit, as is the ability to quickly merge changes from multiple branches.
Finally, as another commenter has already suggested, it's really just about establishing good habits as part of your workflow early. It's much like testing: if you start out with a decent test suite, you're much more likely to maintain and use it than you are if you have to overlay testing onto an established project. Similarly, if you have full version history from day 1, things will be much easier further down the road.
FWIW, multiple backups and hardlinks are the basic foundation of git. Running 'git commit -a' a few times a day to check in all the changes isn't a big timesink; commit messages can take time or not depending on how detailed you care to be.
I've has some personal projects that were 'moving too fast' for version control, or that I was just playing around with. In every case I ended up losing code because I couldn't remember how I'd done something I'd later removed. And I've never had a project with more than one copy of the codebase -- whether that's a local dev and a production deployment, or two devs -- that didn't end up overwriting code or config at some point.
It's not surprising that version control, largely useful for history, does not appear to be immediately useful for a young project. But young projects become old projects with the same habits and practices. Start with good ones.
