On Fri, 2011-01-28 at 12:59 +0000, David Cantrell wrote:
On Fri, Jan 28, 2011 at 10:03:10AM +1000, Michael G Schwern wrote:
> I give a lightning a talk called "Subversion Lifetime Achievement Award", the
> premise of which is that if Subversion hadn't fixed the superficial flaws in
> CVS we never would have seen the fundamental flaws in the model. Distributed
> version control would not have taken off like it had if we were still
> struggling to make a branch. I propose it benefited from all the folks who
> happily and easily used "svn cp" and then found no sane way to merge back.
I have to ask what all those folks are doing wrong. The group I work in
at the BBC uses Subversion to manage two large projects with several
developers. Sure, we occasionally get conflicts, but that's the only
merge problem we have, and I don't see how any revision control system
could prevent them unless, like RCS, it prevents multiple people from
working on a file at the same time.
Perhaps this is a case where RCS's hatefulness is a Good Thing.
No, file locking is pain. It's an entire world of hate. Even the p4 kind
of pseudo locking reduces productivity.
The point of DVCS is that they *do* handle merging better because they
do it in a totally different way. This much reduces the chance of you
ever even seeing a conflict.
For anyone who doesn't grok DVCS yet the link[1] Michael posted
previously is totally worth 15 minutes of your time to read. I'll quote
a chunk from it which I think illustrates exactly why branching and
merging is painful in old-style VCS exactly to your point above:
"Here’s the difference. Imagine that you and I are working on some code,
and we branch that code, and we each go off into our separate workspaces
and make lots and lots of changes to that code separately, so they have
diverged quite a bit.
"When we have to merge, Subversion tries to look at both revisions—my
modified code, and your modified code—and it tries to guess how to smash
them together in one big unholy mess. It usually fails, producing pages
and pages of “merge conflicts” that aren’t really conflicts, simply
places where Subversion failed to figure out what we did.
"By contrast, while we were working separately in Mercurial, Mercurial
was busy keeping a series of changesets. And so, when we want to merge
our code together, Mercurial actually has a whole lot more information:
it knows what each of us changed and can reapply those changes, rather
than just looking at the final product and trying to guess how to put it
together.
"For example, if I change a function a little bit, and then move it
somewhere else, Subversion doesn’t really remember those steps, so when
it comes time to merge, it might think that a new function just showed
up out of the blue. Whereas Mercurial will remember those things
separately: function changed, function moved, which means that if you
also changed that function a little bit, it is much more likely that
Mercurial will successfully merge our changes."
[1] http://hginit.com/00.html
Cheers,
Martin
