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.
Poll: Version Control
61–70 of 92 posts
Re: Poll: Version Control
#62Earlier 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.
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
#63I 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.
Re: Poll: Version Control
#64I 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.
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
#65i'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.
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
#66None. From where I stand, it seems like extra management duty, for marginal benefits.
I wrote more about it here, if you'd like convincing:
http://betterexplained.com/articles/a-visual-guide-to-versio...
Re: Poll: Version Control
#67Re: Poll: Version Control
#68None. From where I stand, it seems like extra management duty, for marginal benefits.
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
#69None. From where I stand, it seems like extra management duty, for marginal benefits.
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.