
Git: The Lean, Mean, Distributed Machine - r11t
http://www.slideshare.net/err/git-machine
======
gvb
Another advantage of DVCS that wasn't mentioned in the slide deck is that,
with git (and other DVCSes), you are _always_ working in a revision controlled
arena. Git's got your back.

When I used RCS, I was always working in a revision controlled arena - all my
changes were revision controlled, assuming I checked them in... and after the
first or second disaster, I learned to _check things in._ Frequently.

When I used CVS/SVN, I lost the ability to always work in a revision
controlled arena (theoretically I still had the ability, but doing it was such
a hassle that it simply did not happen). I ended up checking out a copy from
SVN and then locally revision controlling my changes in RCS. Ugly.

Working without git is like driving without seat belts. You can do it and
probably nothing bad will happen... but if something bad _does_ happen, it is
the difference between walking away a bit sore and an extended hospital visit.

~~~
tolenka
I can't say I understand your point.

With svn, I commit often, as long as the code builds and my own unit tests
pass. If I need to make a lot of breaking changes, I use 'svn cp' to create a
branch and then I can still leverage svn's merge tracking in keeping that
branch up-to-date.

This seems like the same way I use git/hg, but without worrying about
excessively divergent local/remote branches across machines -- I can see your
branches, you can see mine, they're all centrally accessible by definition.

~~~
gvb
If you own the SVN repository, I agree, it works well enough. However, if you
don't have write privileges to the repository or if it is a shared repository
with a lot of other people, it becomes much more difficult.

If you don't have write privileges into the SVN repository, you have no
ability to revision control your changes without creating a tracking
repository of your own. Creating and maintaining a tracking repository is a
hassle, especially compared to a DVCS where that is the normal operation.

If there are a lot of people with write access into your SVN repository,
creating branches doesn't scale well because all the branches are public.
Creating a SVN branch for every experiment rapidly gets out of hand. Again,
you can create a separate tracking SVN repository (hassle) or you can use
branches, but it is nowhere near as easy as with DCVSes.

The big difference with DCVSes is that scaling across lots of developers is
not a problem, branches are strongly encouraged, and merging works _really_
well.

~~~
tolenka
_If you don't have write privileges into the SVN repository, you have no
ability to revision control your changes without creating a tracking
repository of your own._

This is fairly unique to open source software -- it's not something that
occurs in an organization, and should only occur when a user without commit
access is doing large-scale modifications to a project.

Unfortunately, the functionality often used to maintain divergent forks where
individuals fail to push small hacks/changes immediately back to their origin
project.

 _Creating a SVN branch for every experiment rapidly gets out of hand._

Out of hand how? I've worked in organizations where every single feature
received a developer specific branch (eg, branches/tolenka-feature-xyz) and
never ran into trouble.

 _The big difference with DCVSes is that scaling across lots of developers is
not a problem, branches are strongly encouraged, and merging works really
well._

Given merge tracking, merging works more or less the same as a DVCS.

As far as scaling across developers, I'm not sure what the issue is.

------
startingup
Can anyone compare Git vs Mercurial? This decision is coming up for us, and
would appreciate the input.

~~~
ubernostrum
In terms of what you can actually _do_ if you set your mind to it, they're not
terribly different. In terms of the default/conventional things recommended by
their communities, they're fairly divergent.

Speaking as someone who's used both and prefers Mercurial:

* Git's branching philosophy (lots and lots of branches, only one active at a time) can be handy. But Mercurial's philosophy (not quite so many branches, and usually as separate clones so you can work on more than one side-by-side) is, I've found, usually better.

* Git's much more encouraging of editing history up to the point where you share code with someone else. Mercurial will let you do that if you really want to, but it's discouraged; the only "easy" way is limited to undoing the last commit. Git seems to encourage committing much, much more often and not particularly caring about the repository history until you're ready to share with someone else (at which point you just selectively rewrite the history to look sensible). Mercurial seems to encourage committing in logical chunks so the repo history is clear and sensible the whole time (but again, if you really really want to do the Git-style stuff, you can).

* Mercurial seems to me, personally, to be a bit more logical in terms of choosing good defaults and exposing abstractions. Git's choices for default behaviors have been criticized even by its fans, and it tends to throw a lot of its inner workings at you on a regular basis, even if you don't really care much.

But, again, this is only my own personal opinion; undoubtedly others will
disagree with it.

~~~
jbellis
> usually as separate clones so you can work on more than one side-by-side

the major downside here is that all IDEs I know are excellent at reloading
your project from the fs when you git checkout a different branch, but much
clunkier about having to reopen another directory.

~~~
ubernostrum
Which is why I said it's a trade-off.

If you go the git route, then you only look in one place for the code and it's
easy to just point at it no matter what's currently active. But the downside
is that (so far as I know) no tool other than git can show you what's in not-
currently-active branches.

If you go the hg route it's easy to see lots of things side-by-side, but of
course you don't have the "it's all in one directory, and you do have to point
at different locations to work on different branches.

Personally, I prefer hg's approach here.

~~~
rlpb
If you want branches side by side in git, just clone your repository. Or am I
missing something?

The one catch is that the "upstream" repository will be the local one you
cloned from, rather than your original upstream. git-clone could easily have a
switch for that, though.

~~~
ubernostrum
Notice that I've never said "git can't do this". I've been talking in terms of
the conventions recommended by each tool's community. In the case of git,
that's _not_ separate clones for branches...

------
wglb
This is a good introduction to Git. Some of the pictures chosen to illustrate
points are hilarious, like the smoking angel, or the RCS shack.

------
xtho
84MB download for a dia show of cc eye-catching but nevertheless offtopic
images. Wow! Sometimes I really wish people would stick to that dull bullet
points style of presentation -- in at least half of their slides.

~~~
philwelch
Actually, I think this style would have been pretty effective if I was
watching the guy give his talk.

------
RiderOfGiraffes
15:00 Zulu time: URL is down for me: Error: 500.

Will check later.

------
GrandMasterBirt
One thing I dislike about the presentation is it does not give credit where
credit is due. BitMover wrote BitKeeper (I use it atm at work) which was the
predecessor of mercurial and git. Naturally there were issues with being
proprietary till it pissed off the right people causing them to create a new
VCS based on BK. BitKeeper is... pretty damn slow compared to Git. But it was
the innovation.

Also if he mentioned clearcase's performance it would be obvious that
Clearcase is a hut made out of good intentions (we didnt even use sticks at
that point).

