3 reasons to switch to git
markmcb.com
markmcb.com
But svn lacks suh flexibility to interact with others. Hence git > svn, as in svn is a tiny subset of git.
For more information on why git was not chosen instead of svn for FreeBSD you can look at http://wiki.freebsd.org/VCSWhy
Again, each vc has it's uses, and nothing is merely a 'subset' of another.
Git allows working from more than one system at once without requiring a constant server connection. When I'm on the go and want to make changes to my code from my laptop, I can make commits, I've got access to the full history, etc. All that's required is a pull from my desktop before I leave my office, and I've got a shell script that pulls the repositories for all my projects at once.
With something like SVN, this kind of thing was a major pain, as I'd either have to work just with my local copy on the laptop (leading to poorly tracked mega-commits), or copy the whole file system structure of the repository to the laptop, which quickly gets you into desynchronised territory. Add another developer and you're instantly dead with that kind of system.
I can't believe I fell for a celebrity endorsement. ;)
Really, I'd be fine with any fast distributed VCS, which means nearly all of them these days. (sorry Darcs). The ease of setup ("If you have SSH you have a git server") feature is also very nice, but I don't think it's exclusive to git.
I'll wait out the GIT wave. If it's more dominant than SVN in 2011, that's when I'll switch.
I've found that the CVS-to-git workflow is a bit more annoying. You can import CVS repos into git, but you can't really push anything back without using patches.
On our project we deleted the master branch in favor of having two branches we work off of: production and development.
The production branch reflects what is in production while development contains new completed features that each developer builds in all of their own branches.
Does anyone here seriously work like that?
Seems like git has some advantages if you branch a lot, but I don't think branching too much is particularly healthy. I can see why it's good for open source if you have a ton of contributers, but what's the win for a small team who hardly ever branch?
That's the nicest thing I've heard anyone say about SVN ever.
Sure, why not? I create a branch for nearly every series of edits (aside from tyop-fixing bugfixes) that I do, usually to fix a bigger bug or to create a new feature. If it works out, great: I merge it into the master. If it turns out to be a dead end, or is taking too long, I can delete the branch, or just put it aside with the intention of rebasing it later.
...but I don't think branching too much is particularly healthy.
Again, why not? Ignoring for the moment problems which are social at their root and not a dvcs' fault, most likely either you're creating lots of dead ends in those branches, which isn't such a bad thing because it also means that you're also trying out lots of ideas and exploring the problem space; or you're merging those branches, so you're doing good work and getting it integrated into the project.
With a centralized VCS (or more specifically a single- or few-branched repo), you just tell people to checkout code, commit their changes, and you're done. There are less places to screw up because you don't have a bunch of branches you have to manage. You are less flexible, but this lack of flexibility only becomes a huge burden in a truly distributed (i.e. open source) environment.
It's sort of like arguing static vs. dynamic typing. There are many cases where dynamic typing resulted in very painful errors because some variable along the line didn't follow the "gentleman's agreement" that it should be a list and not a string. Though dynamic typing is more flexible and powerful, sometimes you just succumb to human error because the computer trusts you.
anyone want to correct me? i like git in most respects, and am now using it on a few projects.
Did you realize that your master/ branch is just one such long-running branch, and one that's not special in any way other than being the default for some commands...
As far as multiple committers on one branch -- well, you can do it, but with 'git rebase' and friends, it's just easier to do your own work on a short lived branch off your primary branch, and just merge in stuff as you get it done.
It's not that git makes it difficult to do it compared to other version control systems; it's just that it's a nicer workflow if you use short-lived topic branches to do development because you don't to worry about what other people are doing until you decide you want to take a look at it and merge it in. The short-lived private branch + lots of merges workflow is just easier because it prevents interruptions in your workflow.
As far as emailing patches, it's a matter of taste. It's certainly easier to make sure all changes get reviewed if patches are mailed around, because people tend to read their mails. Personally, I just use a post-update hook to mail out a list of changes for each commit, and review them later, since it's always relatively easy to back out or fix a patch -- after all, it is a version control system.
git > svn