31–40 of 40 posts
git init git add . git commit -m "blah" git push origin master
git branch name git checkout
easy-peasy
The author sets up a false dichotomy: Subersion or git. But those are two different models of source control: centralized and distributed. If you want to use centralized source control, the choice is more likely to be cvs or Subversion. The popular notion isn't that Subversion sucks, but that it's pointless. The claim I hear is that it's a reinvention of cvs, but it doesn't actually improve much. Personally, I had to…
Earlier quoted context omitted.
Amen. Meanwhile: To claim that SVN is intrinsically easier to understand than DVCS is to be very shortsighted. Subversion is a more mature technology: It's eight years old, and is conceptually based on CVS, which goes back to the eighties. DVCS is all of eleven years old in its eldest incarnation (according to Wikipedia) and the current generation of tools (git, Bazaar, Mercurial) date back only to 2005. DVCS is a ma…
I understand your point about maturing technology, but distributed anything is usually hard for people to wrap their heads around the first time.
I don't think that's necessarily so. Have you ever tried to get an office full of people to collaboratively author a Word document? What's their instinctive behavior? They all grab copies. Then each of them hacks away on their copies. Sometimes two or three of them email their hacked copies to each other and mash them up, using cut and paste. Eventually some poor SOB has to get everyone to email over their individual versions so he can merge them. Hopefully they've all been using Track Changes (which is, in a sense, a poor man's facsimile of a single-document DVCS!); otherwise it's an even bigger clusterfuck.
That's a distributed model. Ever since the invention of photocopiers and email attachments, people have had to develop a very good understanding of how that model works, and how it fails.
It's tempting to think that the way to sort this out is to centralize it. But in my experience, centralized document-management systems are not that intuitive, which drives people to secretly work around them. ("Why can't I save my changed document on the shared drive? Oh, no, Joe checked it out and then went on eight-week vacation! I'll just stash my edited version on my local drive and distribute it via email." Or, "I created an alternate version of the doc, but I don't dare upload it to the shared drive because I might make another mistake and overwrite the official version. That always makes the admin really mad. So here it is on this USB stick.")
I think the most confusing aspects of version control are the navigation of history (just look at the wacky extreme that Apple' Time Machine designers went to in order to make it very obvious that you're looking backwards in history), and merging, particularly merge conflicts. But those aren't special features of DVCS; they're tricky no matter which VCS you use.
Branching and merging suck in Subversion. Offline commits suck in Subversion. Does that mean Subversion sucks? Depends on whether you want good branching and merging and offline commits. I do; therefore, for me, Subversion sucks. QED.
The author sets up a false dichotomy: Subersion or git. But those are two different models of source control: centralized and distributed. If you want to use centralized source control, the choice is more likely to be cvs or Subversion. The popular notion isn't that Subversion sucks, but that it's pointless. The claim I hear is that it's a reinvention of cvs, but it doesn't actually improve much. Personally, I had to…
Subversion, in my experience, is worth the effort of switching from cvs. It's a breeze to set up, and it's a lot cleaner than cvs.
However, on the 'switch from CVS to SVN', I'll comment and say that SVN is far superior to CVS.
The whole 'changes committed to the repo up the entire repo version' alone make this worthwhile.
SVN is also less arcane in its usage.
SVN has better tools for, well, everything.
SVN integrates well with all major IDEs (mine being VIM, but also Monodevelop and Eclipse).
The switch from CVS to SVN also made our releases much easier to manage (merging branches is fairly trivial and tagging is a no-brainer).
If you're using CVS in a company, do yourself a favour and switch to SVN. The basic concepts are the same, so re-educating developers takes all of 5 minutes.
Here's an idea. Instead of throwing around "Subversion sux", "Git is the new hotness", how about we all just use what works for us and the projects we're working on.
Are there better tools ? Is Git better ? Maybe, but different tools for different uses. For me personally, Subversion does not suck, and I don't need a "better" tool.
It works, and gets the job done for me !
"Even designers can use it." Why does everyone assume that designers are stupid luddites who can't wrap their heads around complex systems? UI design is full of nuance and complexity. It's insulting to designers to assume they cannot deal with DVCS.
It's literally the same argument.
Here's an idea. Instead of throwing around "Subversion sux", "Git is the new hotness", how about we all just use what works for us and the projects we're working on.
In a world without Subversion, Subversion would be built out of Git. In a world without Git, Monotone, Darcs etc. ... well that's where we were 5 years ago, and it sucked.
Did it really suck? I was using subversion in a team of around 15, 5 years ago, and all in all it worked pretty well. It was rare that there would be any issue or that subversion got in the way. Maybe git is better... maybe it doesn't matter enough to bother changing. But you have to admit these types of things are more about what is "in fashion" than what is better suited to a particular task. Things go in big cycle…
DVCS's let you branch off, experiment, and if it works out you can push everything into the main tree with the history included.