[ABE.pm] review of last night's hacking

[Ricardo SIGNES]

* "Faber J. Fedor" <faber at linuxnj.com> [2008-05-08T11:55:16]
> You're going to have to elaborate (not necessarily on the list), because
> I didn't see much of a (functional) difference from what we did last
> night and what Subversion does.  You pulling the changes in looked like
> a pull from the "central repository" from where I was sitting.

I'm happy to elaborate here.

What we did was very close to Subversion's centralized workflow, because it's
easy for most people to grasp if they've already worked with Subversion.  There
were a few key differences:

  1. when you made a commit, you were committing only to your local repository,
  whereas in Subversion your commit would go to the master immediately

  2. you had no ability to send things to a master at all; in fact, there was
  no central master repository, just the "origin" from which you made your
  clone; instead of sending your changes to it, its owner (me) pulled changes
  from you and you pulled more changes from it

(2) is really a central concept to understanding how git can change your
workflow.  All repositories are peers.  None is the master.  The things that
vary in importance are the repostory maintainers.  If you clone the Linux
repository, you can pull from all of the same Linux developers as Linus, and
you can choose to accept and reject different changes.  Now you've got a
repository of Linux as you'd like to see it.  It can contain all the same code,
but with changes merged differently.  It's the technical peer of the kernel.org
repository -- it's just another peer with someone pulling in changes.

The reason it's not as important is that you don't have the authority to
convince the whole world to install your branch.  If you could convince
everyone, though, they could just start pulling from you instead of Linus and
that's that.  People wouldn't have to do anything drastic to start trusting a
different authority.

This becomes more important when you get into doing what I imagine we'll do
eventually: peer to peer change sharing.  It's less complex than it sounds.

The way we worked:

  1. faber and tfreedman clone rjbs's respository
  2. faber commits changes
  3. faber tells rjbs that he's made changes that are ready for production
  4. rjbs pulls from faber and merges those changes into his repo
  5. rjbs tells tfreeman that new changes are available
  6. tfreedman pulls from rjbs and merges those changes into his repo

That's fine when everyone is working on different things.  If faber and
tfreedman are working on the same feature, though, this could happen

  1. faber and tfreedman clone rjbs's respository
  2. faber commits changes
  3. faber tells tfreedman that he's made changes
  4. tfreedman pulls from faber and merges those changes into his repo
  5. tfreedman commits changes
  6. tfreedman tells faber that he's made changes
  7. faber pulls from tfreedman and merges those changes into his repo
  8. faber tells rjbs that they've made changes that are ready for production
  9. rjbs pulls from faber and merges those changes into his repo

Note that in 8 and 9, it doesn't matter whether rjbs pulls from faber or
tfreedman.  They'd have identical changesets, and the authorship of each
individual commit is preserved.  This is another good reason to commit often:
to allow individual changes to be clearly identifiable after merging.

> Actually, I'm more interested in some of your programming techniques,
> like the *_PATTERNS/dispatch table trick.  I want to see what else
> you've got hidden in there.

I could've sworn I posted about that here.  I guess not, though.

  http://rjbs.manxome.org/rubric/entry/1564

-- 
rjbs