[SGVLUG] So you want to know more about Distributed Version Control

Wed Oct 24 03:17:43 PDT 2012

Nice collection of links and commentary.

I just wanted to emphasize the distinction between mercurial and
mercurial queues which is a mercurial extensions.  Mercurial patches
provides a way to apply and remove diff sets to the currently checked
out mercurial repository.  Mq is often useful when deciding how to
group commits, kind of like how you might use the git staging area.
While mq can be quite useful, it is not necessarily the prevalent use
case.

As far as named branches go, they might not be quite as prevalent as
one might guess.  Mercurial encourages creating clones.  Once commits
begin on a clone it becomes an implicit branch.  If the path is no
longer interesting, the cloned branch does not have to be pushed
and/or merged.

On Wed, Oct 24, 2012 at 1:39 AM, Lan Dang <l.dang at ymail.com> wrote:
> I've been meaning to post this to the list for a couple of weeks now, but I
> knew it would take a couple of hours to write up.
>
> tl;dr  If you want to learn about how Mercurial and git and source control
> systems work under the hood,  watch the following videos.  I put down video
> run-times, and commentary.
>
> INTRO
> ======
> I've been studying distributed version control--specifically, differences
> between Mercurial and Git--and came across some great videos that made me
> really understand how they work.  And by this, I mean that an enormous light
> bulb flashed over my head, and I grasped how differences in priorities
> affected the design of these two systems.
>
> One of the  things I learned is that both systems started development around
> 2005, and it's really important to look at the dates on any websites,
> forums, or videos you find on the subject.   They've been evolving pretty
> quickly and while they seem to have converged on similar feature sets, they
> aren't equivalent.
>
> I'm listing the videos in suggested watching order, as I think familiarity
> with certain concepts leads to better understanding of the material.
>
> ==============================================================
> 1) Intland Software - Centralized vs Distributed Version Control  (2012) -
> 1m33s
> http://www.intland.com/videos/centralized-vs-distributed-version-control/
>
> A quick 90 second intro to what distributed version control (Mercurial and
> Git) brings to the table.  No narration, just animation and music.
>
> ==============================================================
> 2) Scott Chacon - Getting Git (2008) - 55m48s
> http://blip.tv/scott-chacon/git-talk-4113729
>
> Recommended for people who have had some exposure to git, but don't know
> what all the talk about blobs and trees and directed acyclic graphs is all
> about.
>
> This video is basically Scott Chacon doing a voiceover for the slides from a
> talk he gave at RailsConf in 2008.  He discusses how git works under the
> hood and some basic uses.  The flow of the talk goes from intro to technical
> details fairly quickly, but the slides are very clean and illustrative, so
> it actually is quite easy to understand.  You need to pay attention because
> he covers a lot of material in a short amount of time, but you will be
> rewarded by an understanding of git's basic architecture.
>
> (He talks about source control taxonomy around 4:05 mark.  Pay attention
> because this is your first hint about how Mercurial and git are different.)
>
> One of the surprising things I learned is that by design all commits are
> immutable.  It's just the pointers to your history that keep moving around.
> git only garbage collects objects that aren't pointed to by anything.  git
> reflog (reference log) is your friend.
>
>
> ==============================================================
> 3) Google Tech Talk: Linus Torvalds on git (2007) - 1h10m15s
> http://youtu.be/4XpnKHJAok8
>
> NOTE: close captioning is excellent on this video.  Turn it on.
>
> This is an entertaining talk.  Linus is pretty opinionated.   Despite the
> title, Linus was actually more interested in talking about the virtues of
> distributed version control systems than he was about talking about git in
> particular.  When you learn about why Linus felt a need to build git, and
> what features were important to him, you have a better understanding of the
> philosophy behind git.  There were several enlightening moments, from his
> rant about what it really means to have cheap branching--which is not
> actually the branching, but the merging--to how important it is to him to
> guarantee the integrity of his source tree, to how a 40-character SHA hash
> allows him to recover his repository, even if it's being hosted by an
> untrusted entity.  More importantly, he talks about how git changed the way
> he worked.
>
> At 40:42, he says something very important on the subject of cheap
> branching, which is that even if it is technically cheap, one of the issues
> with centralized repositories is that you would still feel reluctant to
> branch if the branch is visible to everyone.  You have to think whether it's
> worth it, and then you have to worry about the global namespace and coming
> up with naming schemes.
>
>
> ==============================================================
> 4) Google Tech Talk: Mercurial Project by Bryan O'Sullivan (2006) - 49m41s
> http://youtu.be/iR0rBYI1gy4
>
> NOTE: close captioning is horrible on this video.
>
> This talk about Mercurial precedes the talk by Linus, and reflects Mercurial
> in its early days.  Bryan actually goes into some detail about how Mercurial
> works, including how it does the version control through deltas.  I really
> need to watch the video again, but some things that stand out is that he
> talks quite a bit about a tool called Quilt and applying patches.  He also
> mentions how he tends to develop features as patches instead of using
> Mercurial commits.  At 34:13, he explains why he does that: a) he didn't
> want to clutter the repository history with the experimental avenues he may
> have gone down during development; b) he actually do commits for these
> features, but not necessarily in the repository that they will eventually
> end up in.  If I read his comment correctly, instead of branching the way
> you'd do in git, he actually does his development in a separate repository
> and exports the code as a patch.  This would seem to indicate that while
> Mercurial may have cheap technical branching, you don't want to make
> branches willy-nilly because everyone will see them.
>
> My commentary: You don't have this issue with git because branches are not
> shared between repos unless you explicitly push them.  Also, git has this
> rebase feature that allows you to rewrite history, and one of the use-cases
> is  compiling  a bunch of small commits into one large feature commit.
>
> ==============================================================
> 5) CodeSchool.org: Version Control with Mercurial by Brian Will (2012)
> Part 1 of 5 (13m21s) - intro to source control and how diff works
> http://youtu.be/idd2fmPRRlU
>
> Part 2 of 5 (15m28s) - more on diff, 2-way merge, 3-way merge
> http://youtu.be/uTy1C60NwhY
>
> Part 3 of 5 (24m59s) - Mercurial - changesets, basic commands
> http://youtu.be/-rMc1vyjjas
>
> Part 4 of 5 (23m49s) - Mercurial - merge, branch, tag commands
> http://youtu.be/o4gYcgfEgng
>
> Part 5 of 5 (10m38s) - Mercurial - how to handle branching
> http://youtu.be/Lojweft0CyE
>
> NOTE: close captioning is horrible.
>
> This is a good series, and you will learn a lot about how diff and merges
> work and get an in-depth (and current)  introduction to using Mercurial.  It
> is a bit like being back in school again.  I had to space out the videos
> because it was hard to maintain focus.
>
>
> Lan
>
>
>
>
>