None. From where I stand, it seems like extra management duty, for marginal benefits.
uh.... what?
Poll: Version Control
71–80 of 92 posts
Re: Poll: Version Control
#72i'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.
Selling points to convert me from SVN to Git:
* single directory
* ease of setting up a local repo
* per-line commits (interactive mode)
Re: Poll: Version Control
#73RCS - I'm coding solo and RCS has essentially zero setup.
Re: Poll: Version Control
#74None. 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…
Yes, git does have that effect at first...
I found the bzr documentation to be a great resource for understanding how DVCS (and even centralized VCS) systems are supposed to work.
http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html
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.
Re: Poll: Version Control
#75Earlier quoted context omitted.
It's only a little bit faster than mercurial, and the size of the repository is larger.
Also, the project maintainers seem to place a very low priority on portability. People work on Windows, BSD, and OS X, too.
If portability is a concern, I recommend you check out Bazaar.
Re: Poll: Version Control
#76i'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.
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.
Re: Poll: Version Control
#77Earlier quoted context omitted.
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'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.
It's a good idea to make a branch for each release. Then you can easily look at the code that's in production and make patches.
Re: Poll: Version Control
#78None. 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…
" 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!
Re: Poll: Version Control
#79I 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.
all the Rails kids think git's cool right now
A stopped clock is right twice a day.
Re: Poll: Version Control
#80Can 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?
I wrote a somewhat long article about Git merging:
http://blog.jrock.us/article/Git%20merging%20by%20example.po...