Live data from Hacker News

Poll: Version Control

news.ycombinator.com

61–70 of 92 posts

Re: Poll: Version Control

#61
post #60
post #53

clearcase at work subversion for my personal/startup stuff

my god. poor you. I had to use clearcase a while ago, and it was painful.

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.

Re: Poll: Version Control

#62

Earlier quoted context omitted.

Also, the project maintainers seem to place a very low priority on portability. People work on Windows, BSD, and OS X, too.

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.

* $ grep "#!/bin/sh" /usr/local/bin/git* | wc -l ===> 23

Re: Poll: Version Control

#63
post #3

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. Git's metaphor is not, and most people go batty for it. That's a pretty good reason to change. I wouldn't use git if it didn't have cheap inline local branching. It is the Killer Feature.

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.

Re: Poll: Version Control

#64
post #57
post #3

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 used mercurial briefly and found it to be much, much slower compared to git.

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.

Re: Poll: Version Control

#65
post #4

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.

Re: Poll: Version Control

#66
post #51

None. From where I stand, it seems like extra management duty, for marginal benefits.

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:

http://betterexplained.com/articles/a-visual-guide-to-versio...

Re: Poll: Version Control

#68
post #51

None. From where I stand, it seems like extra management duty, for marginal benefits.

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.

Re: Poll: Version Control

#69
post #51

None. From where I stand, it seems like extra management duty, for marginal benefits.

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.

Post reply on HN