
The fighting's been fun and all, but it's time to shut up and get along - tghw
http://blog.bitquabit.com/2010/02/10/fightings-been-fun-and-all-its-time-shut-and-get-along/
======
rajat
"Their enemy is Subversion"

Sigh! Perhaps the enemy is the still surprisingly high number of programmers
not using any source code control at all. Perhaps we should be working on
educating those who still don't feel the need to use source code control on
their own personal projects. But Subversion?

I just helped on a "major" project that worked remarkably successfully using
good old CVS. I personally prefer Mercurial, and it's what I use for all but
my smallest pieces of code, but did CVS work well for coordinating 50+ chip
designers, software developers, document writers? Hell yes! Not even a single
hiccup, no little thanks to a very helpful and standup IT guy. Good ol' CVS
did the job just fine. Could newer technology be better? Yes perhaps I can
think of a lot of hypotheticals where it would have been great to have a DVCS,
but in practice, I can't think of all that many times where it would have made
much of a difference. The fact that every one there, particularly the chip
designers, knew how CVS worked, had worked with it for years, had their own
work methodologies based on CVS, made the very thought of using anything else
nothing but stupid.

------
Maciek416
The article hits the nail squarely on the head.

Git is pretty awesome, I love using github. From what I've seen of Mercurial,
it is also mostly blessed the same awesomeness.

Getting people to convert is a fairly big undertaking, though, and although
the author touches on this, he might be underestimating the task of conversion
a little bit.

The first of his 3 points (that git/mercurial's inferior handling of binary
files is one of the major issues) is in my opinion dwarfed by an issue he
doesn't even mention: git's cryptic user experience and sometimes insanely-
scary (especially to git newbies) error messages. I've met plenty of coders
who are brilliant programmers but are completely baffled by the very simplest
of operations in git when they fail. I'm not sure a better user experience is
even remotely on the radar of the folks who work on git, so for git newbies,
it's back to svn.

Has anyone else noticed this?

I'd love to get my day job's project moved from svn to git, given the
tremendous benefits (we experience a lot of pain when branching our svn repo),
but the pain of moving has to be eased significantly. Moving a repo like ours
doesn't just involve importing the repo, it involves training, dealing with
all the errors and hangups, figuring out how to make our ancient installation
Trac talk to our repo, connecting it to Eclipse and NetBeans, and adjusting
all of our build processes. I think if the day to day git experience was less
cryptic, we could probably handle the remaining issues.

~~~
weaksauce
What is wrong with using git-svn on your local machine instead of trying to
migrate everything over to git?

~~~
Maciek416
Well, partially my personal ignorance with how that would work :) But also..
my team often has to break into pairs to work on sub-projects and new
features, and it would be nice to have everyone on board rather than just a
single person. The whole package is compelling. Thanks for the idea though.

~~~
weaksauce
You're welcome. git-svn is an interface to a svn server that handles the
interaction with the svn server. You checkout from the svn server. Do local
git stuff and then when you have a completed feature/bugfix you use git-svn to
push it back to the svn server.

Food for thought at least.

------
maxklein
The closer two things are to each other, the more they fight. Like the Hells
Angels vs Bandidos, or the Bloods vs the Crips. I mean, coming as someone who
is not involved in any crime, it would seem reasonable that the Hells Angels
should battle the Crips, seeing as they totally represent different things.
But no, they go fight the people closest to them.

What I'm trying to say is that Git is like the Hells Angels, Mercurial is like
the Bandidos, and SVN is like the Crips. Microsoft Visual Source Safe is like
MC Hammer.

~~~
raganwald
> The closer two things are to each other, the more they fight.

<http://en.wikipedia.org/wiki/Narcissism_of_small_differences>

~~~
pavel_lishin
I figured the reason would be competition for a similar niche.

------
aarongough
I'll come right out and admit that I still use Subversion. And like it.

That seems like a crime to most people because I'm a Rails coder, but the
truth is that I haven't had any need of anything else yet. I'm generally the
only person working on my projects which means that Subversion meets all my
needs.

I'm sure that there are benefits to converting, but every time I start the
process I get turned off by having to learn a whole new way of doing things...

For now: I'm sticking with Subversion.

~~~
thibaut_barrere
I'll second that - for 2 customers, we're just back to SVN, actually (despite
I'm using Git for my own projects, because I like to commit offline, mostly).

The learning curve of Git is way too steep for non-technical participants in
particular, at least in my experience, whereas they seem to handle SVN without
much difficulties.

------
ryanwaggoner
_It’s easy, in the yin/yang of Hacker News and proggit, to forget that most
developers are not even aware of what DVCSes are or what they do._

Can this be true? I'm definitely not a rockstar developer and I've been using
Git for more than a year.

~~~
eli
You'd be surprised how many people still use CVS.

~~~
pavel_lishin
You'd be surprised by how many don't use any kind of CVS.

~~~
ryanwaggoner
I'm actually not surprised, and I've worked on plenty of client projects where
the "workflow" was to login via FTP and edit live files on the server. If
there was a chance for a potential conflict, just yell across the room to the
other developer to make sure you don't step on each other.

Sadly, a few of these were for large interactive agencies. I try and steer
clear of these kinds of jobs when I can, or at least try and push them towards
svn or git.

~~~
briancooley
I worked for a client that used this exact method, plus comments in the source
to indicate who changed the code, with old code commented out. I was one of
several developers working remotely. It was a mess.

When I suggested version control, the reply was "We're not big enough."

Sigh.

------
nollidge
"It’s easy, in the yin/yang of Hacker News and proggit, to forget that most
developers are not even aware of what DVCSes are or what they do."

It's also easy, in the yin/yang (what?) of Hacker News and proggit, to forget
that there's plenty of developers RIGHT HERE who do not grok DVCS. I sort of
know what they are, and that they making branching suck less or something.

Hello, I'm nollidge, and I don't get DVCS. Where do I start?

~~~
steveklabnik
For me, it was watching Linus' Google talk on git, and then reading some
tutorials, and then just doing it.

    
    
        Linus: http://www.youtube.com/watch?v=4XpnKHJAok8
        GitReady: http://gitready.com/
        Pro Git: http://progit.org/book/
        A short little bit about git's internal model: http://eagain.net/articles/git-for-computer-scientists/
        GitHub's Git Cheat Sheet: http://github.com/guides/git-cheat-sheet
        A successful git branching model. gorgeous workflow and pictures. http://nvie.com/archives/323
    

Also, if you have any questions, feel free to email me. The only reason
someone should be using SVN now is if there are institutional reasons or if
you use lots of large binary files. I'd rather you send me an email about
something that seems hard than give up and use an inferior tool. I'm not an
absolute git master, but I've ended up explaining it to most of my classmates,
so I've given that explanation a few times already.

~~~
nollidge
At work we have LOTS of large binary files, yes. Static dependencies in C#.
But I'll give it a go for personal projects.

Thanks!

~~~
steveklabnik
No problem. It's something that's being worked on, just merging them becomes a
pain. If your dependencies are truly static, in the sense that you're not
modifying them or updating them often, it shouldn't be a big deal. Usually
it's large images or other 'asset' type stuff that causes a bloated repo.

------
dlsspy
It's the sort of next step in the blub problem.

People are coming from a world where they see svn as being _so_ much better
than cvs (and source safe and what-not), but the only thing close to it in its
class is p4, and they have to pay a lot for that, so it doesn't count.

Then someone convinces them that there's a better class of things and they
want to give it a shot. git users talk about the power and wonders of git. hg
users talk about how much easier it is to use than git. bzr jumps up and down
slowly and says, "me too!"

In this sense, DVCSs are each other's enemies preventing our own adoption.

I've used hg a _lot_ and I've been using git almost exclusively for a couple
of years. A project whose source is in git is more likely to get contributions
from me because it's just easier for me. Projects that use hg will get a
contribution if it's a big enough pain because it means more work for me.

------
raganwald
Odd, but as I was reading this I kept thinking of programming language flame
wars:

> So why is there so much hating? I think what’s going on is that people are
> coming to these languages from Java or PHP, have their massive epiphany on
> how totally awesome these languages are, and then assume that only their
> language can have this level of awesome, so they begin evangelizing. The
> problem, of course, is that the other guy feels the same way, and is also
> evangelizing, so the Ruby and the Python guy end up in a locker-room-style
> temper-tantrum over whose language has the best frameworks or whatnot,
> instead of how much more awesome their languages are than the competition.

> This has to stop.

> Python’s enemy is not Ruby. Ruby’s enemy is not Python.

> Their enemy is Java.

------
asnyder
Poor Darcs, it's not even considered. I remember how awesome I thought Darcs
was, but now we're almost done switching to Git. I would've stayed, but Git
lapped Darcs on tools, performance, and stability. A shame.

~~~
mbrubeck
The author of Darcs is writing a git porcelain that uses the Darcs command-
line interface and patch semantics:

<http://github.com/droundy/iolaus>

~~~
asnyder
There's also darcs-git, which is a python script that allows you to run darcs
command in git. [http://git.frugalware.org/gitweb/gitweb.cgi?p=pacman-
tools.g...](http://git.frugalware.org/gitweb/gitweb.cgi?p=pacman-
tools.git;a=blob;f=darcs-git.py;hb=HEAD)

------
sshumaker
I've always had this issue with Mercurial - if you're actively developing and
want to fetch updates from the upstream, you are forced to check in to your
local repo, even if the code you're working on isn't ready to be checked in.
Git might do a better job that mercurial with git stash, but mercurial's
equivalent (hg shelve) sucks - when you unshelve, rather than generating
typical conflict markers, it generates patch diff files, which are way harder
to work with. When you're developing with a small team, this happens all the
time. After a project wrestling with mercurial, my team forced me to switch
back to SVN.

I tried using git (with git-svn) to work around this, and even with the easy-
git porcelain, the learning curve (and cryptic errors) were ridiculous
(basically, easy-git is a pretty leaky abstraction). There's absolutely no
reason why a VCS should be that hard to use.

~~~
tghw
The problem is easily solved with smaller, more frequent commits.

In SVN, your changes had to be "ready to check in", which was this big,
complicated ritual where you back up your changes, update, merge, check to see
if the merge screwed with your changes, replace your backed up files, diff,
unfuck the merge, and finally, commit.

With DVCSs, there's no reason not to commit partially done features. If you're
at enough of a stopping point to want to merge in other people's changes,
you're at enough of a stopping point to commit what you have so far. Your code
only needs to be "ready" when you push it out.

~~~
sshumaker
I'm sorry, but this last point simply isn't true. Sometimes I'll be building a
new feature, and I'll expose a bug which another dev will fix and check in, or
another dev will add some hooks for me. The new feature definitely isn't ready
to check-in, but I need to get their changes to continue.

~~~
tghw
That's my point, this "ready" concept is just a holdover from SVN. There's no
reason a commit has to be "ready" in any way. You can even say that in the
commit message.

~~~
sshumaker
I agree with that. However, if you been making intermediate checkins, it's
more difficult to cherry-pick changes to push upstream. Especially if you've
been doing lots of intermediate checkins - it's easy to forget which changes
were intended to be real (as opposed to dummy code you've put in for testing,
etc), and push selectively.

Maybe this is easier in Git, but it has the worst interface I've ever seen,
and that's saying a lot.

~~~
tghw
If you're considering cherry-picking, you're still thinking in an SVN mindset.
We did the exact same thing for a while before figuring it out, with some help
from a few people who had used DVCS longer. You just have to use it for a
while and you'll start to see the workflow where this isn't a problem.

~~~
sshumaker
We used mercurial for almost a year before the team rebelled and forced a
switch back to SVN. :) It was all of our first experience with a DVCS.

It's not just cherry picking - if you've spread changes across multiple
commits, it's much more difficult to manage them. Yes, you can diff cross
revisions. But that's more awkward. Worse - if you commit so you can merge in
changes from the mainline, all of your changes get lumped together - which may
be logically different fixes - and some may even be debugging code that
definitely shouldn't end up in the mainline. If you later need to push a
subset of your changes, you're in for a world of hurt.

I guess if you get people to use patch queues religiously, you can work around
this. But patch queues (in mercurial at least) are definitely rough around the
edges, and have their own share of problems.

I'm guessing this process is better in Git. But if I can't deal with the
interface, there's no way I'm going to convince the rest of the team to do so.

If people have suggestions on how to deal with this kind of stuff, I'd love to
hear people's suggestions. My HN username @ gmail.

------
weaksauce
His point about binary files is true. Until it gets as good as SVN at handling
binary files then it probably will not have an easy time getting people to
convert.

How likely is it that Linus will add better support for binary files from an
outside project or do we just have to use the forked git?

~~~
jrockway
_His point about binary files is true. Until it gets as good as SVN at
handling binary files then it probably will not have an easy time getting
people to convert._

I don't think I've ever stored a binary file in my source-code control system.
(Hint: your VCS is not your backup server.)

(Yes, OK, I have a favicon.ico in some of my repositories. This has not
detracted from the "git experience".)

~~~
jws
Turn 100 developers loose and amazing things happen to your "source code"
repository. I used to find entire images of Microsoft CDs in ours. The
developers wanted to be able to get to known state for compiling, Visual
Studio and anything else they were using went in to CVS, and later subversion.
Then because they had so much trouble with different versions of the Visual
tools making different output they started checking in all the built DLLs and
executables.

The developers should have been soundly thrashed with a cane, but if it is
possible to check in a binary. They will do it.

~~~
prodigal_erik
If you want to reliably maintain (or even build) a given version of the code,
it's the right thing to check in the versions of the compilers and build tools
that are known to work. A good tool is small, fast, meant to be run non-
interactively, and takes instructions in an easily-reviewed file. Making your
official build in Visual Studio is a bad idea for all these reasons--even
Microsoft doesn't do that, at least when I contracted there. (They used a make
clone with some extra support for metadata from win32 binaries.)

------
d0mine
Summary:

 _Mercurial’s enemy is not Git. Git’s enemy is not Mercurial.

Their enemy is Subversion._

 _.. most developers are not even aware of what DVCSes are or what they do. ..
The goal right now, if you honestly believe that the DVCS workflow is
better—and I do—should be to get the mindset out there, to make more people
aware of what DVCSes have to offer and why they should be using them._
</quote>

------
Estragon
This kind of thing makes me feel the same way I do about lisp: I've tried
both, and I'm still struggling to understand what the hype is about.

