
Distributed Version Control is here to stay, baby - mattyb
http://www.joelonsoftware.com/items/2010/03/17.html
======
graywh
"If you are using Subversion, stop it. Just stop. Subversion = Leeches.
Mercurial and Git = Antibiotics."

This is great. A few years ago, DVCS was weird and strange and SVN was the
stuff. When people discover how awesome Git and Mercurial are, they stab
SVN/CVS in the back.

~~~
Sukotto
That's just life in technology as the tools improve.

1) Stop manually backing up versions, that's error-prone. Use RCS!

2) Stop using RCS, it doesn't scale. Use CVS!

3) Stop using CVS, it's too complicated. Use SVN!

4) Stop using SVN, it makes it hard to merge branches. Use Hg/GIT!

... And someday, we'll be saying 5) Stop using Hg/GIT. They ________. Use
_______!

Same thing for hardware, and languages, and frameworks... and just about
everything. _shrug_

~~~
axod
It's funny how it's usually easier to ditch X, and write Y from scratch,
rather than try to improve X.

~~~
Jasber
I agree and don't think it's limited to programming. Considering business,
it's difficult for a large established organization to make drastic changes.

It's much easier for a new entrant (startups) to innovate because they don't
have the same baggage.

~~~
mechanical_fish
Yes, where by "baggage" you mean "vitally important existing customers, users,
and dependencies that will break if you change anything".

~~~
Jasber
Yes, I do.

But that doesn't change my statement.

If you're not willing to break your business to change with the times, someone
else will--and by the time you react it's too late.

------
bruceboughton
But _how_ does thinking about changes rather than versions make things easier,
Joel? You never quite explain...

~~~
axod
A version is just a changeset, so for me, it makes little sense to claim
"changes" are a completely different way of thinking than "versions".

Perhaps it comes down to how you divide work up. I just don't like branches.
They're mess.

~~~
abstractbill
I don't like branches either (we've been using git for maybe a year now at
justin.tv, so I've definitely had the opportunity to grow to like them).

Actually I think one of the biggest reasons I don't like them is that they're
a kind of "hidden state". If someone made a VCS (or just an _interface_ to an
existing VCS) where branches were just represented by different subdirectories
in the filesystem, then I might use them more.

~~~
lutorm
That _is_ how branching works in svn, you make a copy to another directory on
the repository.

~~~
abstractbill
I know how svn branching works - I don't think I explained myself clearly.

I'd love a RCS that would let me see every branch that currently exists
_without having to check them out_. The branches would exist as directories on
my _local_ filesystem. Any file operations (doing a directory listing, or
accessing a file) on these local directories would actually be doing RCS
commands and pulling data over the network, but I wouldn't have to think about
that anymore.

~~~
lutorm
If you checkout the svn root, you get all the branches as directories in your
local filesystem. After that, it seems it would be the same as what you're
saying.

Besides, you can do svn ls to see the branches.

I must be missing what you're getting at.

~~~
LaPingvino
I think he means that the way you work is the same as in SVN but the way the
system works is like Git etc.: the branches are editable and accessible like
directories but with the advantages and changeset-construction of Git behind
it.

Am I right?

------
praptak
"The interesting part is that these systems think in terms of changes, not in
terms of versions."

Not git. Git's repository model is very strongly snapshot-oriented. Of course
the whole machinery for supporting changesets exists in git, but it is built
atop a system that actively avoids "thinking" in terms of changes.

Linus on this: [http://marc.info/?l=linux-
kernel&m=111314792424707](http://marc.info/?l=linux-kernel&m=111314792424707)

~~~
weavejester
I don't think that link contradicts Joel. Git represents repositories as a
network of diffs, not a linear history of versions.

~~~
praptak
This is not true for git's object model (which I believe maps to Joel's "user
model".) Quote The Git Book:

 _"Subversion, CVS, Perforce, Mercurial and the like all use Delta Storage
systems - they store the differences between one commit and the next. Git does
not do this - it stores a snapshot of what all the files in your project look
like in this tree structure each time you commit. This is a very important
concept to understand when using Git."_

Source:<http://book.git-scm.com/1_the_git_object_model.html>

However the diffs are there below the snapshot-based model as means of
effectively storing and transmitting the snapshots.

~~~
nas
Conceptually git thinks about snapshots of trees. The pack format uses deltas
but that's a mostly hidden detail. The pack format didn't exist for the first
months of git's existence.

I haven't bothered to read the blog post (Joel strikes me as someone with a
huge ego and without any exceptional insights), but doesn't the above fact
mostly refute his thesis? I like git and hg but they are just tools. You could
do the same development model with patches.

------
steilpass
"we developed a new way of developing software using if statements instead of
branches." Is that critizing feature flags? Or is more to that?

~~~
axod
It often makes sense to have 2 alternate implementations of a component in the
same codebase, so you can switch between them at startup/during runtime, and
compare them side by side. Something that isn't as easy to do if you create 2
separate branches.

~~~
etherealG
I think a better solution is to have both features in branches, and have a 3rd
branch which allows realtime switching between the 2.

a nice upside is that you can merge changes to each feature up into the
"combined" branch as they get stable, to test side by side. when you finally
finish, you can leave feature a behind by merging b into your release, or vice
versa. or maybe even merge both into mainline.

sorry, the point I was trying to make is that cheap branching and merging is
still an easier way to manage this situation than just ignoring branches
altogether.

~~~
axod
In what way easier?

A: Create separate branches, manage merging/updating unrelated changesets.

B: Create 2 implementations of something in code, and manage nothing.

I guess it depends on how easy it is to isolate the part you want to create 2
implementations of, so it may depend on what language you're using as well as
how you architected things.

Branching+Merging just seems like something extra I have to do, manage, and
remember. Like filing. And I still can't see what benefit it gives for many
cases.

But that's fine I think... I just don't get it. Maybe I'm too old ;)

------
omergertel
It helped me to think about it in terms of connected graphs. Nodes are
versions and arcs are changes. A path between two versions is the aggregation
of changes. Merging then becomes walking down the same path, but starting from
a different node. I start at my current version node, and I walk down your
path of changes. It's very different than trying to merge two nodes.

(This is just my mental model, no need to read into it more than that)

------
fnid2
So is Joel's blog apparently.

~~~
gruseom
He implies in the last paragraph that it's his final post. Still, I think
there's a point here. Writing, when you're that good at it, isn't so easy to
give up. Also, the blog has been a huge part of Spolsky's success. So I bet
he'll revive or continue it in some form before too long.

Edit: I hope he does, too. I probably disagree with him more than half the
time, but there are few other writers on software who consistently hold my
attention, and almost no one who consistently makes me laugh.

~~~
Periodic
I would be happy to seem him move to a more personal blog. Something that is a
little more about his personal experiences with technology. It sounded like he
didn't like the regularly-published business-oriented posts.

I wouldn't mind a picture of Taco on each post.

------
jackfoxy
I've only lived through one version control migration, that was from TFS to
Subversion. The problem we have is the length of time Subversion takes doing
updates, commits, and merges when you are dealing with a large repository and
many changes spread out among files. (Good old TFS was fast.)

Can anyone say if Mercurial is significantly faster?

After going through Joel's tutorial it looks like Mercurial keeps history from
branches in the root much better than either TFS or Subversion. I think I
would opt for Mercurial the next time I have to set up source control.

~~~
kneath
I can say without hesitation mercurial or git will be _insanely_ faster for
these operations. Remember, you work locally, and then push with hg/git. So
when you do "git commit" it only relies on the speed of your hard drive/cpu.
Commits happen instantly. Updates are needed very rarely (since you don't need
to update to make new commits). Merges are so much faster it's not even funny.
After merging in hg/git you wonder why SVN even had a merge functionality.

In addition to those conceptual differences, the actual act of transferring
files between remote and local on git/hg is also _much_ faster than SVN.
Entire checkouts of git repositories are usually smaller (disk size) than the
equivalent SVN checkout... of one version. This means less time on the network
all around.

~~~
jackfoxy
Yeah, committing to your local copy better be fast, it's committing to the
shared server repository that I'm concerned about.

~~~
chousuke
I think you'll find that whatever git does, it's faster than the corresponding
operation in SVN.

When you send commits to a remote server, git compresses them and sends the
packfile over the network. The server will refuse non-fast forward merges (the
branch you're pushing is supposed to be merged by you first, locally) so it
pretty much has nothing to do but uncompress the changes and apply them.
Unless you have a really slow network or are sending an insane number of
commits, it's not going to take longer than a few seconds.

Cloning big repositories (like emacs, with ~25 years of history) can take a
while if you have a slow network, but sometimes it feels like git can actually
clone a repository faster than SVN can check out a single revision.

But repos like emacs' are rare. Often, SVN repositories end up being huge
because they contain the code of many unrelated projects. In Git, having such
a huge repository is impractical; each project should have its own repository.
There is support for submodules though, so you can make a "master" repo that
contains pointers to the child repositories, if you really have to.

------
ableal
There's something bothering me about the hosannas to the power of merging
changes. Isn't there an unspoken assumption that all your work is text files ?

If we talk drawings, photos, whatever binary data is needed for a project -
what happens ? Are the binary deltas as good as SVN's ?

Even if the "binaries" are XML text - e.g. drawings in SVG - wouldn't I be out
of luck trying to merge changes if 'Beth' added a squiggle and 'Cath' a square
to different parts of the drawing ? (many tools, upon writing, reorder data
'ad lib'). Are there "merge tool" plug-ins ?

~~~
schacon
Binaries are not merged - if histories diverge and one side changes but the
other does not, it will choose the side that changes. If both sides change, it
will record a conflict and you have to choose one side (or create a new binary
that you tell the system is resolved). You can run an external merge tool with
'git mergetool' and there are over a dozen it knows how to run, but I don't
know which of them will handle images. You can also use .gitattributes to help
you diff binary files efficiently, but you still have to either choose one
side or manually create a new binary. I mean, even a merge tool won't help
much there - if you have images that changed on two different branches and you
want to combine them, you have to fire up Photoshop or something anyways -
that's almost always going to be a manual process. Though, in the four or so
years I've been using Git (and the years before that with SVN and CVS and RCS)
I don't remember having to do that very often - thus is the life of a coder, I
suppose. The people who create and modify images for programs tend not to
tread on each other.

Also, this is really the same problem even for systems without solid branching
capability, like SVN. If two people modify a binary image at the same time and
one commits, then the other will get a merge conflict when they update and
will have to solve the conflict in order to commit.

------
revorad
Blogging is hard to give up, Joel?

Edit: Uh stop upvoting me please. That was a tongue-in-cheek comment and, as
sant0sk1 pointed out below, also lazy on my part.

~~~
spolsky
Not at all! Today is the ten-year anniversary of my first real post, so I've
been planning to have my last real post on 3/18 for a long time.

Thanks for all your attention over the years. I'll still be around, just not
doing these essays any more.

~~~
run4yourlives
btw, Kiln looks really cool, especially the visual code tree. Your interns
deserve a pat on the back for that.

~~~
queensnake
Are you referring to this?:

[http://www.fogcreek.com/Kiln/learnmore.html#hist_BranchAndMe...](http://www.fogcreek.com/Kiln/learnmore.html#hist_BranchAndMerge)

That's about standard, the free 'gitk' does that much, too, for git.

------
abalashov
For me, it always has been and always will be a right tool for the job issue.

We work on relatively small code bases with a very small team of people, not
large, unwieldy open-source projects with hundreds of contributors. Primary
interest is in a log of what has happened to the code chronologically, rather
than applying/unapplying specific revisions/hunks frequently. No need
whatsoever for people to run with their own branches. With those requirements,
git, Hg or Darcs would all present far, far more headache than they're worth
versus Subversion.

In some other scenarios, the formula may yield a different outcome...

------
swolchok
That backpack anecdote is a play straight out of Guy Kawasaki's _The Macintosh
Way_ ([http://www.amazon.com/MacIntosh-Way-Guy-
Kawasaki/dp/00609733...](http://www.amazon.com/MacIntosh-Way-Guy-
Kawasaki/dp/0060973382/ref=sr_1_1?ie=UTF8&s=books&qid=1268951347&sr=8-1)),
which is on Joel's recommended reading list for managers
([http://www.joelonsoftware.com/articles/FogCreekMBACurriculum...](http://www.joelonsoftware.com/articles/FogCreekMBACurriculum.html)).

------
smokinn
What an excellent way to go out. Great last article Joel.

------
10ren
It's a DAG. The arcs are diffs (edits).

------
po
What's wrong with a jalapeño bagel?

------
Aegean
How this article got so much points I'll never know. Its some novice advice on
version control. Why don't you read the git books, they'll tell you all about
it in well-organized fashion: <http://book.git-scm.com>

~~~
Aegean
Agree: Upvote, Disagree: Downvote. _That_ shouldn't be the way to go. I insist
the article is novice advice. At least take the time to reply on how you find
it original rather than simply downvote.

