
Abandon your DVCS and return to sanity - drostie
http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity#
======
iand675
Anyone else remember the days when having your SVN server go down meant that
you more or less had to wait until the server came back up before you could
get back to doing things? (if you wanted a nice atomic commit). Let's not
forget people that have to travel a lot for work– SVN + airplanes is a match
made in hell.

Anyone else ever had someone delete or close an open source project that you
cared about? Finding a copy with the history that mattered to you could be
tricky.

Anyone else ever needed their own fork of something due to differing goals
from the parent project, but needed to fold in upstream changes relatively
often? That's by nature the sort of problem that a DVCS solves easily.

Other objections to this article:

* Nothing precludes you from using the patch model with DVCS (I mean, Linux kernel development uses Git just fine with this)

* The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap. Another point worth mentioning is that you can make shallow clones with Git. I don't know what the status is for committing to them these days, but there's nothing fundamental that should prevent a DVCS from letting you work on shallow clones if space is such a big deal.

I could go on, but the article seems to be griping about UX issues. Just
because we haven't had tools in this space with wide adoption that are user
friendly doesn't mean that we won't eventually.

~~~
Xylakant
> Anyone else remember the days when having your SVN server go down meant that
> you more or less had to wait until the server came back up before you could
> get back to doing things? (if you wanted a nice atomic commit).

That's now known as "I can't deploy because github is down". Note that the
author proposes "local commits plus a centralized storage".

> The author mentions that you have to retain the whole history of a project.
> For one thing, storage is cheap.

Not in portable computers. I can get a TB, but that's it. I have build
artifacts that clock in at about 300 - 500 MB and I'd version control them if
possible. I can't, because that would fill my disk within a couple of month,
so I have to push them to a server and somehow link them.

> Anyone else ever needed their own fork of something due to differing goals
> from the parent project, but needed to fold in upstream changes relatively
> often? That's by nature the sort of problem that a DVCS solves easily.

That's a strawman. The article does not argue that there's no use-case that's
solved by git or and DVCS. It's just that not every use-case is solved by git.
I'd even go out and argue that most use-cases are solved just as good by a
solid centralized system with less complexity involved.

> Just because we haven't had tools in this space with wide adoption that are
> user friendly doesn't mean that we won't eventually.

I see a developer wedge his git repo with a pull + rebase about once a month.
And then somebody needs to walk over and explain. DVCS fundamentally introduce
complexity that is not always needed. And I doubt that the fundamental
complexity can be abstracted away.

~~~
jimktrains2
> That's now known as "I can't deploy because github is down". Note that the
> author proposes "local commits plus a centralized storage".

And in that cause you can scp your repo somewhere and change your origin and
move on.

Also, do people really rely on 3rd party services for their deployed code?
I've used github as a repo and colab tool at companies, but we still deployed
from repos owned by the company.

> I'd even go out and argue that most use-cases are solved just as good by a
> solid centralized system with less complexity involved.

I'd go out an argue that because the added complexity of git is far outweighed
by the benefits of a local repo.

~~~
Xylakant
> And in that cause you can scp your repo somewhere and change your origin and
> move on.

If you happen to have - god forbid - a php app that pulls dependencies via
composer you have a hard dependency on github since composer pulls practically
all code from GH. I don't consider that a good idea, but that's how it
currently is. [No, I don't do php and only sometimes have to clean up the
resulting fallout]

~~~
ksenzee
That's not a hard dependency, it's a sensible default that you should be
overriding if you're running composer install as part of your deployment
process instead of including composer's vendor directory in your repo.
Documentation:
[https://getcomposer.org/doc/05-repositories.md](https://getcomposer.org/doc/05-repositories.md)

~~~
Xylakant
Practically all packages use git sources. Yes, you can vendor them -
congratulations, you just kicked the can down the road and moved the issue to
the build step. The issue exists for other languages as well -
maven/mavencentral, ruby/rubygems.org - but only composer depends on github
very much. I don't like that but it's not like the other solutions are much
better.

~~~
mercurial
Many companies mirror maven, so having mavencentral go down is not a big
issue. Does composer make it possible to deploy a mirror of its dependencies?

~~~
ksenzee
Yes, certainly: [https://getcomposer.org/doc/articles/handling-private-
packag...](https://getcomposer.org/doc/articles/handling-private-packages-
with-satis.md)

------
jimktrains2
> Note: we fell in love with DVCSes because they got branching right, but
> there’s nothing inherently distributed about a VCS with sane branching and
> merging.

No, I fell in love with it because it was distributed and I could work without
an Internet connection, which aren't prevalent everywhere, and even in my
house, in a large city, can be iffy. By work I mean things like blame, bisect,
log, &c not just committing.

> Let me tell you something. Of all the time I have ever used DVCSes, over the
> last twenty years if we count Smalltalk changesets and twelve or so if you
> don’t, I have wanted to have the full history while offline a grand total of
> maybe about six times.

Well lucky him for only being able to code when he has a nice connection, not
all of us do.

Also, I like the distributed aspect as well. I like not having to give people
commit access to my repo for them to have a proper dev env and then they can
send me a patch or a PR and we can incorporate their changes. How would they
be able to make any commits or anything otherwise without access to my
repository?

~~~
Xylakant
I call that filter bubble. I like using git for local commits, but 15 out of
20 persons here don't even take their laptop with them and I bet that 17 out
of 20 won't touch code on the road. Maybe at home, if they have to. A decent
centralized VCS would totally do.

There are a lot of companies that actually would prefer if the code never left
the premises and have a use-case for finer grained permissions (some folks can
only touch the assets, others can only ever see the dev branch, can't see
history,...), things that are by definition not possible in a DVCS.

Storing large assets in git sort of suck and requires ulgy hacks. I'd love to
version the toolchain and the VM images for the local development environment,
but that's just not feasible with git.

I consider git a perfect match for loosely knit teams that are spread around
the world and travel a lot. It's a great tool for OS development, but it's
advantages quickly evaporate for teams that sit in a centralized location with
a good connection to the server (cable, Gigbit) and only ever work from there.

~~~
amyjess
> I consider git a perfect match for loosely knit teams that are spread around
> the world and travel a lot. It's a great tool for OS development, but it's
> advantages quickly evaporate for teams that sit in a centralized location
> with a good connection to the server (cable, Gigbit) and only ever work from
> there.

Yes, I think what a lot of people forget is that git was designed specifically
with the Linux kernel in mind. Linus wrote it to the workflow of his project
without much regard for what other projects do. That's fine; there's nothing
wrong with that at all. It just means that it's not suitable for every
project, and that's a good thing: different types of projects should use tools
that are actually designed for them.

It also explains why git has such a strong learning curve: it was written for
kernel hackers. The only people who were expected to use it are the kind of
people who are used to delving deep into the nitty gritty. It's why I'm kinda
disappointed GitHub became the dominant public source code host, because
Mercurial is IMO much better at actually being penetrable to new users. I
think people who are mostly familiar with SVN would be far, far more at home
with Mercurial than git.

~~~
silverbax88
Mercurial beats Git hands down across the board for me. I've worked on so many
projects where the initial development was tossed into Git and then the devs
spend three days trying to get their codebases synced and each using a
different tool which may or may not implement the core commands of Git.

Mercurial? Works everywhere much more simply, even ties into .NET with
VisualHG and gives a better version/branch management than TFS. And doesn't
mismanage disk space like Git.

Mercurial + BitBucket is the cleanest, fastest way I have right now for adding
devs to new projects. I avoid Git because so few people (ESPECIALLY those who
have only used Git) understand source control well enough not to make a mess
of it.

~~~
erikb
> each using a different tool which may or may not implement the core commands
> of Git

That's really one of the core problems of using git and why it's not for
everyone. If you want a tool to do your job then git won't make you happy.
Using the core tools and learning how it works _inside_ is the only way to
make it work efficiently.

If you want/need a bike (something easy like svn), use a bike. If you
want/need to use an air plane (git) you need to learn how to fly and that
costs a lot of time. Putting something on the plane to make it look like a
bike (a tool that may or may not enable all of git but probably not) won't
suffice in either case.

------
cssmoo
Unpopular opinion here but we're using SVN here on a large project. No
intention of changing it. Why?

1\. Deterministic "whodunnit" as we have AD integrated with. That is needed
when you have 220 people using a repo.

2\. Partial check outs. Our platform is 6MLoC in total.

3\. TortoiseSVN. Sorry there's nothing else out there as good as that. We use
it for DMS tasks as well as you can merge word docs etc.

4\. Binaries and locking. Works for design workflows and the odd file we can't
merge easily (git/mercurial aren't magic bullets for that).

5\. Centralised. All our shit is in one place so there's a "single source of
truth". Also no patches flying around.

6\. Easy to backup and replicate. Svndump into single file. Or svnsync and
there's a true copy.

7\. Perfect tooling/tracking integration due to the centralisation and hook
support.

8\. Easy to use for mere mortals (excel/word pokers).

9\. Forces backup behaviour. A specific case but we had a couple of people
using git and then pushing to our svn. One SSD fail and bang, the guy lost a
week of work because he didn't push to master.

Merge tracking is a non issue since 1.7 and if you need to work offline, just
create patches and check them in when you're back online. Also our svn
instance has been down for 3 minutes in the last 8 years...

I really can't justify a move to a DVCS and lose all the above so I'm quite
happy with my sanity.

~~~
phaemon
I am honestly baffled by your points 1 & 2.

You have 220 people working on 6MLoC and you think git can't handle this? You
are aware that git is used for the Linux kernel, right? I mean, it must be its
most famous use case.

~~~
ufo
1) Unlike the linux kernel, cssmoo's project has lots of large binary files.
If he used git the repo sizes would blow out of control and designers would
lose the ability to lock the files they are working on (locking is important
because you can't merge binary files after the fact)

2) His organization is very different than what the Linux kernel does. Linux
operates in a hierarchical manner where each subsystem has a maintainer that
collects patches and sends them up to Linus. This system makes full use of
Git's DVCS capabilities but its not perfect for everyone.

------
brockers
The best part of the whole article was the line:

>> "If you say something’s hard, and everyone starts screaming at
you—sometimes literally—that it’s easy, then it’s really hard.

------
balabaster
Hahahaha love this. But I think all version control systems suck - not
inherently, but because their usability is atrocious. I enjoy Git... well,
perhaps enjoy is a strong word, perhaps what I really mean is I have Stockholm
Syndrome.

I've tried to go back to TFS, SVN and other centralized systems, but I'm too
emotionally bonded to having my source control system with me, everywhere I
go... Starbucks, Tim Hortons, the Train, sitting on the beach. But I don't
delude myself into thinking this is anything more than emotional. I _like_
having it there, it gives me comfort - and there is _some_ convenience.

I don't want to have to worry about "How do I undo all those changes from my
last 10 commits and go back to where I started down this path?" Git gives me
that nice fuzzy feeling of being able to play meaninglessly with my code until
something takes form and if it comes to nothing, I can do git reset --hard
1f3c2047 and I'm right back to where I was before I went down this path of
insanity...and if it takes a nice form, I can do git rebase -i and squash all
my messy commits into a single commit with a single commit message. I didn't
need to branch, I didn't need to clone, I didn't need to do anything crazy, I
just fire up Bash and I'm done, no muss, no fuss, no having to be connected to
the source control server, no dependence on anyone else... and if I _did_ want
to put that code aside, I can stash it or spin it onto another branch before
coming back to my original branch and resetting back to a sane commit. It's
nice having ultimate control.

But having that amount of control has its drawbacks...you can't expect the
ability to drive stick, but not have to learn how to use a clutch and
gearshift.

------
jlarocco
> Let me tell you something. Of all the time I have ever used DVCSes, over the
> last twenty years if we count Smalltalk changesets and twelve or so if you
> don’t, I have wanted to have the full history while offline a grand total of
> maybe about six times. And this is merely going down over time as bandwidth
> gets ever more readily available. If you work as a field tech, or on a space
> station, or in a submarine or something, then okay, sure, this is a huge
> feature for you.

Or if you're a Kiln customer, and their site is taking 4 minutes to load a
page, assuming it's not just down...

Sorry, couldn't resist...

Seriously, though, I don't see where the author is going with his rant. It
doesn't say much, and almost seems like a snide jab at Git and GitHub.

None of his points are very good. Yeah, it doesn't take a DVCS to treat the
whole repo as a unit. But right now they're the only ones who do. A
hypothetical patch to SVN doesn't help me much.

Also, I know from experience that SVN is horrible at binary files, and
especially horrible at large binary files. I'm not saying Git and Mercurial
are great, but they're no worse than SVN.

The entire section about the amount of books and documentation is just silly.
There was a LOT more subversion info around than "just the Red book". I owned
two books, and I know we had a few different ones floating around the office,
not to mention boatloads of tutorials and guides online.

It's also funny how he makes fun of GitHub's git tutorial, but doesn't mention
Kiln's Mercurial and Git tutorials. He also rips on GitHub's pull requests,
but fails to mention that they work better than Kiln's.

But it's great to see the founder of Kiln telling everybody not to use the
technology his company is based on...

~~~
stsp
> Also, I know from experience that SVN is horrible at binary files, and
> especially horrible at large binary files.

Bug reports to users@subversion.apache.org please. Or it didn't happen ;-)

~~~
durin42
Indeed. I work on hg a lot (and custom git servers some), and I'd be quick to
tell you that Subversion is a _lot_ better in the common case than either git
or hg on large binary files.

------
zo1
>" _The actual reason is because GitHub let coders cleanly publish code
portfolios, and GitHub happened to use Git as the underlying technology to
enable that,_ "

Is this guy genuinely suggesting that people fell in "love" with distributed
version control solely because of GitHub? I don't feel _old enough_ to be
telling this author to get off my lawn. I mean, GitHub is great and all, but
it does not represent the sum whole of all the commits in this world.

Granted, does anyone know the timelines of when DVCS took off (as opposed to
launched)? Mercurial and Git were both released a good 3 years before GitHub
was launched.

Okay, I looked up more about DVCS. Wikipedia article's history section on it:

 _History

Closed source DVCS systems such as Sun WorkShop TeamWare were widely used in
enterprise settings in the 1990s and inspired BitKeeper (1998), one of the
first open systems. BitKeeper went on to serve in the early development of the
Linux kernel.

First generation open-source DVCS systems include Arch and Monotone. The
second generation was initiated by the arrival of Darcs, followed by a host of
others.

When the publishers of BitKeeper decided in 2005 to restrict the program's
licensing,[5] free alternatives Bazaar, Git, and Mercurial followed not long
after._

~~~
vezzy-fnord
I think both of you are respectively overestimating and underestimating the
significance of GitHub.

Are there a lot of projects that use Git without a hosting intermediary
because of genuine advantages? Yes, absolutely. Plenty of core infrastructure
and applications, many of which significantly predate Git or GitHub.

Is there a growing subculture of people who essentially equate Git with GitHub
and end up completely subverting the "D" in DVCS, incurring unnecessary
downtime and who pretend Git/GitHub are the be-all-end-all? Also yes, with
circles such as those of HN being overrepresented with "GitHub is your resume"
rhetoric and various startups or hip SaaS having GitHub be their single point
of failure.

Being the #1 software hosting site in the world does have an effect on
demographics, at the end of the day. By now Git and GitHub have an essential,
if controversial relationship.

~~~
stsp
Back when I followed the long discussions about introducing git at the ASF
(now live at git.apache.org) several git proponents said that git without
github is pointless to them. I was quite surprised how adamant some people
were about that. Before then I never thought of github as a sort of GUI for
git, just as... one service for repository storage out of many, I guess?

The ASF has a strict policy of self-hosting. So git repos are now mirrored to
github from ASF intrastructure, for the github fans who initially suggested
the reverse (ignoring obvious problems such as ASF having no influence over
what happens at github).

------
pron
Note that the author of the article doesn't advocate forgoing local commits,
but something like Facebook's work on a semi-distributed Mercurial, which
allows local commits without cloning the entire history to each client. Here's
the relevant section from the linked post[1]:

 _But what if the central Mercurial server goes down? A big benefit of
distributed source control is the ability to work without interacting with the
server. The remotefilelog extension intelligently caches the file revisions
needed for your local commits so you can checkout, rebase, and commit to any
of your existing bookmarks without needing to access the server. Since we
still download all of the commit metadata, operations that don 't require file
contents (such as log) are completely local as well._

[1] [https://code.facebook.com/posts/218678814984400/scaling-
merc...](https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-
facebook/)

------
MichaelGG
Git snapped into focus and I've had little problems since I was told it's
simple a DAG, and all the branch/tag/etc. stuff are just labels pointing to a
part of the graph. After that, I've seriously never been in a situation where
I was totally at a loss as to what was going on.

Also, even in SF, Internet connectivity is often flaky enough that requiring a
network roundtrip for anything to deal with my files is a non-starter. (Right
now, downtown SF, and we only have a single Internet provider option. It goes
to ~100% packet loss about 20 times a day. We get about 10-15Mbps out to the
wider Internet (but 10x more to servers nearby - probably a shitty ISP using
HE or something). So it's really quite a negative to need connectivity to do
things.

~~~
barrkel
Yup. I spent less time learning in total how git works than I have spent
trying to figure out workable branch merging in svn.

(For the latter, I ended up developing scripts that worked with patches as
first class objects, so that e.g. every bug fix that needed to be applied on
multiple branches would actually live in a patch file as my personal way of
tracking a unit of work.)

As to distribution, I spent 5 years as a remote developer working for a CA
company from London. 200+ms round trips and occasional VPN weirdness meant
painful sessions with svn. Having a local repo is excellent. Large binaries
that constantly change are still a problem though.

------
samrift
Here's my problem with this article: Return to sanity by adopting what?

I work on several small-ish projects, and due to the leads coming and going,
there are a smattering of source control solutions. On a weekly basis, I use
SVN, TFS, and Git about equally.

However, the workflow supported by Git is by far the best for me: I can commit
locally as much as I want, rebase the commits or just merge them with work
other people are doing, bisect if I broke something, and even branch locally
to experiment or when I get interrupted by a question or another task.

Neither TFS nor SVN support this at all. With both of them, I can't really
check in until I'm completely done and sure I won't break the build or tests.
I end up zipping my directory or fighting with patches/shelvesets that don't
do what I want.

Now, does the way I want to work require a DVCS? I don't know - perhaps it
doesn't in a theoretical sense. However, DVCS is the only one that _actually
supports_ that now.

So sure, we all push to the same repository and it could be a centralized
system. But what would actually work? What can I switch to? I'm not abandoning
Git for TFS or SVN, that's for sure. Nor Perforce which was also painful.

Yes, you convinced me I don't need the "D" in DVCS. So make a CVS that
supports local branching, commiting, sane merging and diffing and show it to
me! But complaining that I'm not using one of the features of my DVCS has no
bearing on if I should abandon it or not.

------
dasil003
The author gives an excellent opening summary of the fundamental architecture
of common VCSes over time, and then accurately identifies the most painful
points of (eg) git, but then dramatically understates the benefits of a good
DVCS.

If you need binary files or otherwise very large repos, or centralized control
and auditing, or non-developers to work with it, then git has major drawbacks.
However there is so much code in the world—probably the majority—that works
incredibly well with the full benefits of having it all in a single git repo.

Having the whole history and the ability to mutilate it at will in a very
fine-grained fashion is a power tool. I like it for the same reason I like
vim: the learning curve is steep, but the idea is that this is a core tool I
can use across programming languages for the duration of a 40, 50, 60 year
career. I don't want to conflate something as horrible as svn with a
theoretical good centralized VCS, but I have to say that using svn for 5 years
I had much less idea how it worked then I did after 1 year of using git. Even
though git was a steeper learning curve, the concepts in it are well-defined
and the low-level pieces in it have a clarity of purpose which allows some
implicit reasoning about the way things work without having to go in and
actually read the source. This allows the fluent practitioner to devise
flexible approaches to individual problems that a less modular system can not
provide.

I see commit messages and history as a fine craft. With git you can commit
everything in small units that make sense only during construction as you are
still exploring the problem space, then you can rebase it into cohesive
changesets with deep documentation and a continuously unbroken build. A
centralized VCS user could only achieve the same by withholding intermediate
commits; that's okay, but it can become unwieldy for large changes. With git
you can use initial commits like a master woodworker uses scrap wood,
structuring them one way for building, and then discarding them in favor of
finished pieces built to stand the test of time, providing massive forward
benefit in terms of documentation/bisectability. Having worked on at least one
project with a 7-year history, I can testify that investing in history
curation pays huge dividends and can well make the difference between your
successors thinking of you as a solid developer or a shotgun-programming hack.

------
kstenerud
Problem 1: Developers unaware of the full capabilities of their DVCS system
(thinking they can't do work because github is down). Solution: Education.

Problem 2: Lots of versions of big blobs. Solution: git clone --depth 1
remote-url

Problem 3: Big commit history. Solution: git clone --depth 1 remote-url

Problem 4: Bad UX. Solution: Write a better UI, or find someone to do it.
Linus is not a UX guy and never will be.

Also, the example workflow differences are pretty similar to the differences
between the github model and the Linux contribution model. This has nothing to
do with DVCS vs VCS.

So, in short, there's no actual fundamental problem with DVCS. Nothing to see
here. Move along.

------
matthewmacleod
Of all the problems we have as an industry, I'm convinced that version control
is near the bottom of the list.

Sure, 'DVCS' in the form of git or mercurial doesn't deal well with binary
files, and has large repo sizes. If these are problems, you might be using the
wrong tool.

But that's fine; pretty much everybody should be using something like git or
mercurial. They're flexible, relatively easy-to-use, and cover almost all use
cases. If you need to store large frequently-changing binary blobs, then you
are probably in a minority; there's nothing really wrong with git-annex for
managing that content.

But this whole thing we're seeing at the moment with people objecting to DVCS
utterly mystifies me, as someone who went from CVS to SVN to git and has
utterly no interest in going back.

------
averell
>The people yelling at you are trying desperately to pretend like it was easy
so they don’t feel like an idiot for how long it took them to figure things
out. This in turn makes you feel like an idiot for taking so long to grasp the
“easy” concept, so you happily pay it forward, and we come to one of the two
great Emperor Has No Clothes moments in computing.

This part doesn't make any sense. If anything, people would want to convince
you it was _hard_ to not look stupid for taking long.

That being said the phenomenon clearly exists, but the reason is probably more
along the lines of calling everything easy to try look smart in general.

~~~
redshirtrob
This drove me crazy too. I do not know anyone who conspicuously takes a long
time to learn something, and then claims it's easy. In fact, it's quite the
opposite, as you mentioned.

Now, I have observed cases where someone inconspicuously took a long time to
learn something and then claimed it was easy. This was more to elevate one's
own intelligence in the eyes of another. As in, "Wow, this is really hard, but
Joe said it was easy. He must be super brilliant."

The other prevalent case of this behavior is when reading mathematic proofs.
Often times you'll run across a statement in a proof along the lines of: "It's
easy to see that X is true," for some statement X. But, X is always an
existing result, and so this is really a way to focus on the details of the
proof at hand and not get bogged down in proving every single non-trivial
step.

In fact, when I was a Mathlete, our coaches instructed us to make use of this
approach, even if we weren't 100% sure that X was true. If we were pretty sure
X was true, but we couldn't remember the proof, and we knew it would take
prohibitively long to derive the proof, then we would make the statement.

------
joosters
I think the author is just misunderstanding most people's use of version
control. We learn a tool well, so we continue to use it in situations where it
might not be the best for the job in hand, or might be over-engineered for the
purpose. Git falls into this use case a lot because once you understand how to
use it, why not continue to use it, even if the project doesn't really need
distributed version control. It's a waste of time to learn a new system.

Personally I've never even bothered to learn git. I used to use Perforce at
work, now I use it for my own projects. It does the job well, why switch?

------
erikb
There are so many comments, probably nobody will read this. But I have to say
it any way.

The author seems to know a lot about many different things. But still it feels
like he falls into the same trap as most people: Things never really just
work.

Life is always way more complicated than we would assume at first. SVN does
not make most people happy, because it is more simple. If it is more simple
there are a lot of things it can't do.

Some people do something fast and simple for you and you think it works. But a
week later a coworker needs to spend half the week to make it actually work.
And even 10 years later you spend a significant amount of work to make it do
things it doesn't do by itself.

Learning a complex tool to do a complex task is really getting you closer.
Because after you have spent the time learning it you can spend the same short
time periods to achieve a much wider range of tasks, solve much wider sets of
problems with each solution, etc.

------
gfunk911
I fell in love with Git because I could do frequent local commits that matched
my workflow, only "publishing" them when it was appropriate, in the format I
wanted. Git did this for me, Subversion didn't.

I know that concept does not have to be inherent to the D in DVCS. But for me
that was the killer feature. It changed everything for me. The gain from being
able to do that dwarfed all the costs of learning Git.

------
sergiotapia
I think the DVCS issues he mentioned are solved entirely. Just use the simple
git-flow branching scheme.

master = Code that is production ready.

develop = Code for staging

feature/XXX = Feature branches.

Where is there room for confusion? It's dead simple and makes working with
teams so easy and effortless. I would never join a team that uses something
like Subversion or Perforce in these times.

Git sucks for large blob files - no doubt. For those I recommend using
Veracity.

------
pointfree
I wouldn't call darcs ( [http://darcs.net/](http://darcs.net/) ) a failure.
Darcs development is humming along and 2.11 is nearing release.

Gone are the major performance issues with exponential merges and more
recently, pushing large files.

[https://www.mail-archive.com/darcs-
users@darcs.net/msg18423....](https://www.mail-archive.com/darcs-
users@darcs.net/msg18423.html)

[https://www.mail-archive.com/darcs-
users@darcs.net/msg18425....](https://www.mail-archive.com/darcs-
users@darcs.net/msg18425.html)

After having used git, darcs is a joy to use.

~~~
lobster_johnson
I and my teams used Darcs in two startups around 2005-2007, back just before
and after 2.0.

When it worked, it was pretty good. Darcs' UI was close to ideal. The
interactive record prompt, for example (which git got after a while with the
"-p" flag), was great. The way Darcs was able to infer dependencies between
commits automatically and treat it more as a "sea of patches" rather than a
linear history meant that it was very easy to work with branches.

The problem was that as our codebase grew, it increasingly did not work. The
infamous exponential conflict problem was just one of several bugs and
performance issues that ended up costing us a lot of money in lost
productivity. The problem was that when something went wrong, you probably
couldn't fix it yourself. The only people who actually understood the internal
database — not just the files on disk, but how it all fit together, including
the "patch theory" — were the Darcs developers themselves, and not many people
except David Roundy actually understood it from top to bottom. The fact that
it was written in Haskell (which, at the time, was a lot more obscure than it
is today) just made things worse.

After a while we also found that the lack of a linear history had major
downsides. Patch dependencies meant it was harder to cherry-pick; when you
wanted to pick just one commit, it was often impossibly to understand why
Darcs wanted to also pick a bunch of unrelated commits along with it, and from
there on it got messy (and you increasingly risked bumping into the
exponential merge bug). Git's history-rewriting tools cause more conflicts,
but are ultimately simpler and easier to understand.

Darcs' tragedy is probably that its performance problems burned so many people
that they gave up and left it for Git or Mercurial, never to come back. We
might have stuck with it longer, if it hadn't been for the aforementioned
issues. On the bright side, even if Darcs hadn't had these issues, we probably
would never have had a Darcshub.com, and Git would still have beaten the
competition.

------
kardashev
I used to work at a place where our dev team was split in 2 and separated by
500 miles. We had centralized source control and there were days when our
company network was slow. On those days I had to wait 30 minutes to check a
file out and 30 minutes to check a file in. Try to meet deadlines with a
workflow like that.

Never again.

------
nightski
Are these complaints all against DVCS? It seems a lot of them if not all are
just shortcomings of currently available offerings (git/mercurial) whereas the
author is directing them at DVCS directly.

------
jnowlan
Great article. Funny and knowledgeable. I know it's impossible but many of the
comments here make it look like they didn't read the article. I guess if we
followed 'best practices' we would be good.

------
baldfat
I use GIT for backup. the D allows this to happen and if I goof I can always
go back to where I was. Always worth it for a single workflow.

------
joewood1972
Not to diminish the argument, but other than diskspace, I really don't
understand the downsides described here. I'm wondering, given the author was
an early adopter of Git, this is purely hipster syndrome. Everybody is using
it, so it's not cool any more.

------
huu
I don't think the existence of more books for git as opposed to svn proves
that it is more difficult. I think it's more a reflection of how
popular/accessible git is, and publishing more books is a way for the market
to address a bigger audience.

------
hpaavola
What are the (open source) centralized version control systems that do merging
and branching like git?

------
Morst
You do not have to clone the whole history of a repo with GIT. Solves most of
your issues.

~~~
Morst
git clone --depth <n> <url>

------
latj
The author mentions that SVN is going to have branching. Users have had the
ability to use branches in SVN via SVK for over a decade. Thats not the reason
we switched to git.

We switched to git because it made more sense and worked better, because every
operation was faster in git, and because the development of the project was
sure to progress. Github became popular years after git was already spreading.

~~~
ternaryoperator
>Github became popular years after git was already spreading.

That's technically true, but the implication is not. There was less than three
years between the launches of git and GitHub. While git was becoming popular,
it was just one of several (D)VCS solutions. GitHub is what really separated
it from the rest of the pack.

------
sytse
Great article and a good wakeup call on what to improve in Git. I don't agree
that git-annex is centralized by nature. You can choose to download all the
binaries and upload them to another server. Not everyone might do that if it
is multiple TB's but it is much easier to work with multiple remotes than in a
centralized system

------
drawkbox
With DVCS or any VCS you don't have to always have the full history. If it is
a public project and open source you might want that. But if you are working
on games or apps you might want a clean new remote after every so often so you
aren't sending around a TB repo.

When bitbucket limited to 2GB for repos, this limit can easily be breached on
game projects, but it helped to really git submodule out libraries/code. This
also encourages resetting history in a new repo every so often when that
history is really not needed, like 2-3 versions back or after many
months/years. Distributed VCS databases can get immense, but like anything in
life, maintenance every once in a while helps. For some projects this is not
possible like a linux kernel but for any old web site, app, game etc this is
something that you can and should do.

All operations are faster when your DVCS repo sizes are smaller.

~~~
brianpgordon
If you're periodically clearing out your repository history, you're missing
out on an extremely useful tool: blame.

[http://mislav.uniqpath.com/2014/02/hidden-
documentation/](http://mislav.uniqpath.com/2014/02/hidden-documentation/)

------
etep
This: Git is so amazingly simple to use that APress, a single publisher, needs
to have three different books on how to use it. It’s so simple that Atlassian
and GitHub both felt a need to write their own online tutorials to try to
clarify the main Git tutorial on the actual Git website.

~~~
ambrice
So, going by the number of books and tutorials metric, java is a much more
complicated programming language than erlang? Have you seen how many books and
tutorials java needs?

~~~
maaku
Yes, Java is orders of magnitude more complex than erlang. What kind of
comparison were you trying to make?

~~~
ambrice
I knew that no matter what languages I picked for my examples, that someone on
hn was going to respond that yes, in fact language B is much simpler than
language A. I believe you understood the comparison I was trying to make and
I'm not interested in a discussion about how simple erlang really is, it's
besides the point..

~~~
maaku
No I do not understand the comparison. Java's syntax, virtual machine,
libraries, _everything_ is orders of magnitude more complex than the erlang
stack. And indeed, proper introduction and reference of Java can fill a whole
bookshelf, where as a couple of printed technical reports does the same for
erlang.

Back to the original topic, git is also way more complex than a DVCS needs to
be (compare e.g. with monotone, or just about any other DVCS). And any DVCS is
way more complex than even the most difficult to use centralized repositories.
So I think the OP's point is valid. There is at least corrolation going on
here.

~~~
ambrice
So you do believe that if there are more books and tutorials about a topic
that means its more complex?

~~~
maaku
It's Bayesian evidence that the subject might be more complex, yes.

------
makmanalp
> No, the only thing that a DVCS gets you, by definition, is that everyone
> gets a copy of the full offline history of the entire repository to do with
> as you please.

> Of all the time I have ever used DVCSes, over the last twenty years if we
> count Smalltalk changesets and twelve or so if you don’t, I have wanted to
> have the full history while offline a grand total of maybe about six times.

> That’s fine for a centralized system. You only have one copy at any give
> point, so the amount of disk space you need is basically the size of the
> current (or target) version of the repository—not the whole thing.

> This means that changing a file in a deep directory will require generating
> new trees for every directory up the chain—and, of course, that figuring out
> what changed in a given directory requires loading up all the trees going
> down the chain. Wondered why git blame runs slow as hell on big repos? Now
> you know.

(is this even true? Git blame is slow because it digs through history)

> Git is so amazingly simple to use that APress, a single publisher, needs to
> have three different books on how to use it.

People will write books about anything because people will read books about
anything.

> Indeed, to listen to this, you would believe that open-source development
> was impossible, or at least absolutely horrible, before GitHub sprang into
> melodious existence.

The pull request critique is so silly I'm not even going to try.

\----

I really don't see how _any_ of his critiques have to do with DVCS vs VCS.
Literally none of them. This really is a Git rant.

If you don't like Git, I guess that's fine. The problem with git is it's more
building block than slick foolproof user tool, but some of us like it that
way. Git is the first prominent example of someone thinking hard about the
low-level theoretical implications of version control (the idea of the state
of the entire repo as a changeset, the underlying data structures, etc), and
then building a tool around it that works well. When I look at SVN, for
example, it's not obvious what the hell we were even thinking - there was no
theoretical framework, it was just the simplest thing that worked. And it
didn't work well. Branches were more of a pain than a feature. So yeah,
there's obviously room for improvement, but I don't even understand the
complaint against DVCS in general here.

edit: formatting

edit2: or rather, it's about the current state of DVCSes, but I don't see how
most of these would be made better by switching back to a centralized VCS and
I'm not convinced that improving these are mutually exclusive with having a
distributed version control system. I think there's come conflation of
concepts going on here.

~~~
eos_styx
Is there a way to fix your formatting?

------
jrochkind1
I like a lot of things about git over svn... the 'distributed' nature actually
_isn't_ one of them, I think a canonical source location is about the only
sane way to manage distributed software development.

However, I think it's the distributed nature that leads to the much more
powerful branch/merge functionality, which IS top on my list?

(Git's UI is also not one of the things I like the best. It is a mess, indeed.
Yes, because it was not originally intended as an end-user UI. So what, it is
the end-user UI anyway, and it's a kind of ridiculously confusing and
inconsistent one).

------
karmajunkie
I had no idea there were so many repressed SVN-loving developers out there.

------
greggman
svn isn't really a solution for binary files. It also requires workarounds.
Sure it doesn't have the issue of every version of every blob but it still
needs 2 versions of every blob. If you're on a game with terabytes of source
data which is common for a AAA game 2x terabytes is not a win.

It also doesn't help you manage collisions by locking every UNMERGABLE binary
file so you know before you edit if someone else is or has already edited the
file.

I know you can set local options to make it lock the files but that feels more
like a workaround.

~~~
stsp
Binary files are by definition unmergeble with a diff3 algorithm
implementation that uses text tokens separated by \n. Specific software to
merge a binary file format can be used with virtually any version control
system if available.

You can set an svn:needs-lock property on binaries. It is not a local option,
it applies to everyone using the repository. For extra convience, use
svn:auto-props (acts recursively) to set it by default on new files which
match a particular filename pattern (e.g. match on file name extension).
[http://subversion.apache.org/docs/release-
notes/1.8.html#rep...](http://subversion.apache.org/docs/release-
notes/1.8.html#repos-dictated-config)

EDIT: That said, I agree that some types of binary files really have no place
in SVN repositories. One example are release artifacts, as stored e.g. in
Maven repositories.

------
mark_l_watson
Interesting article. svn's scruffiness contributed to git's success.

A little off topic: I tend to work on projects by myself, especially since I
have more or less turned off my consulting business. I have some git repos
that I have been tempted to rm .git, git init, git add remote origin, and git
push -u --force origin master. I have deep backups of everything so losing
history to save a lot of space would be good. I didn't used to care about disk
space but my two favorite laptops have moderate sized SSDs.

------
tomjen3
Give me a centralized system that allows me to branch as easily as git, and
has git stash.

Is Git crap? Yep, unfortunately people went with github over bitbucket,
despite bitbucket having a much better pricing model and as a result git is
what people use for a DVCS.

I would love for somebody to write a centralized version control system that
would be a complete replacement for SVN, the way SVN replaced CVS but until
somebody does a DVCs is what we have.

------
novaleaf
TLDR; Large binary assets are handled poorly by Git/Mercurial.

I too have been bitten hard by this. Being a mercurial user, I tried large-
file-extensions but on a team this leads to file corruption/non-
synchronization too often to be practical.

The most practical "solution" I've found is to actually ignore the issue. When
your repository gets too bloated, start a new one.

~~~
sytse
Consider using git-annex, it is quite good. We include it by default in GitLab
Enterprise Edition.

------
Guthur
I think the problem for this guy is Git. In my opinion Git user experience is
plain horrid, nothing to do with DVCS just Git. Personally I find Mercurial a
lot more pleasant to use.

Not sure how repo size is really an issue in the age of multi terabyte
personal storage, it's even possible to get SSD of that size without breaking
the bank.

------
bnastic
Whenever I see an article like this I remember that Fossil and Perforce exist.
And then I forget about them the next day.

------
syntern
I think that a combination works best, but it looks like not many do a central
SVN + local git setup. Any reason for that? Do you have bad time with that or
what?

The central SVN is much better for tracking versions for release purposes,
while the local git has all the benefits of working on one thing than
switching to another.

Any thoughts?

~~~
syntern
Basically this:

[https://www.kernel.org/pub/software/scm/git/docs/git-
svn.htm...](https://www.kernel.org/pub/software/scm/git/docs/git-svn.html)

[http://flavio.castelli.name/2007/09/04/howto_use_git_with_sv...](http://flavio.castelli.name/2007/09/04/howto_use_git_with_svn/)

[http://andy.delcambre.com/2008/03/04/git-svn-
workflow.html](http://andy.delcambre.com/2008/03/04/git-svn-workflow.html)

------
moron4hire
Is Git really that hard to use? I know it took me awhile to learn how to find
the right documentation for things, but that's significantly easier these days
thanks to StackOverflow and the like. All told, I don't find Git significantly
more difficult than the other tasks I have to do for my job. Usually, the
troubles I have had with Git were because I tried to do something the wrong
way.

And if you don't like the documentation, well, there's more than one way to
contribute to an open source project.

And you could make an argument about Git specifically having bad UX in certain
ways, but that isn't an argument against DVCS in general.

There are problems and bugs with every VCS out there, but I've never
encountered one with Git that left me completely useless for a day, or with a
completely corrupted, unrecoverable repository. I've heard of such things
happening in Git, but it hasn't happened to me in 5 years of using it. I've
had that happen to me, personally, once every 8 to 12 months using SVN. The we
thought SVN was a godsend back then was because it wasn't the 3 to 4 months
that was SourceSafe or the monthly rate that was CVS.

Okay, I'm being bit hyperbolic there, but not by much.

And you can model centralized VCS in DVCS--evidenced by the fact that many
peopled _do_ do that with Github and it's ilk--meaning that systems that can
only do centralized VCS are _defective_. Git can do everything SVN can do, but
SVN can't do everything Git can do.

If your central SVN repository goes down, you're pretty much SOL until it
comes back, and you might even be SOL if and when it _does_ come back. If
GitHub goes down, I'm _mildly inconvenienced_ when I have to add a new remote
to my repository when I need to, say, share code with a colleague, or perform
a deployment.

The argument about contributions is... it's not about Git or DVCS at all. It's
about GitHub and/or bad project maintainers. And he even admits that, but then
acts like he's delivered a blow against the general concept of DVCS.

The argument about blobs is an argument against Git, but not DVCS.

I can't speak to Hg or Baz. I've heard they are easier to work with than Git.
But I just can't imagine giving up the things Git gives me to go back to SVN.
If someone on one of my projects suggested such a thing, it would seriously
call into question for me that person's expertise.

~~~
ufo
Its a bit annoying that I still have to frequently go back to stackoverflow
whenever I need to do a git operation I haven't done in a while. Git doesn't
have strong abstractions and the commands are organized in a very adhoc manner
so its hard to predict how something will work without having to go check some
documentation.

------
talideon
He seems to have forgotten that most DVCSs allow you to perform lightweight
clones, so you don't need to pull down the whole repo.

------
walkon
Logic: claiming to be a current apologist of DVCS while simultaneously
positing that DVCS should be abandoned.

------
dgemm
The comments here trying to rebut every argument against DVCS are missing the
point. The point is not that DVCS sucks and we should all go back to SVN -
it's that since DVCS is fashionable, it is seen as a solution to _every_
problem.

Eventually this will wear off, and we will go back to using the simplest tool
that gets the job done. For some jobs this will be DVCS, for others it won't.

------
grabcocque
Github link to his proof-of-concept centralised VCS that doesn't suck..?

That's what I thought.

~~~
terrywilcox
Why would anybody writing a new VCS use Github to host it? Wouldn't it make
more sense to use the new VCS itself. You know, eat your own dogfood?

~~~
jusio
Not everyone is using GitHub for source hosting, there quite a few companies,
which use internally some other VCS (like Perforce) and publish the sources on
GitHub.

