Fwd: [Python-Dev] Primer on distributed revision control?

[Stephen J. Turnbull]

Ian Clatworthy writes:
 > > although Arch (and implicitly git and Mercurial)
 > 
 > I'm never seen Git and Mercurial as being in the first camp with Arch. I
 > see them as being in the second camp with Bazaar and always have.

OK, I may be reading something into it that isn't there.  Nonetheless,
I think the patch you submitted is a good idea, in case I'm not the
only one with such delusions.

 > The tools in the first camp IMO are Arch, SVK, Monotone and Darcs,
 > though the latest version of Darcs is moving into the second camp
 > now by the sound of things.

FYI, I think Darcs is in big trouble; they still don't have a handle
on the combinatorial merge explosion problem, though they've improved
the algorithms.  Between that and the rarity of Haskell probrammers,
they're having great difficulty maintaining critical mass.

 > > is deprecated as "not ready for prime time distributed tree
 > > revisioning"
 > 
 > I'm not sure where that quote is coming from. I don't ever recall
 > making it.

I'm sorry, it's not a quote of you.  I'm referring to an American
comedy TV show, Saturday Night Live, whose cast dubbed themself the
"Not Ready For Prime Time Players".

 > Did you mean to change into branches after the mkdir? As suggested, all
 > projects will share the repo.

Yes, I left out that step (as I often do in reality ;-).

For the rest I'll need to take some time to review the new version.  I
noticed that in your reply to Paul Moore you said that you'd like to
put more details of architecture and data structures (or whatever,
details not relevant to my point) into the BUG.  I have some
reservations about that.  First, I don't think a sweet spot of just
enough details exists.  Second, I think you're shooting at a moving
target.

YMMW FWIW IMHO etc: One reason I'm an XEmacs developer is the XEmacs
Internals Manual.  It's way incomplete and always out of date, but
even some people who work on GNU Emacs recommend it as good reference
for internals of Emacsen.  It's good enough for the purpose of
bringing new ahckers up to speed.  Maybe that would be a better way to
go (ie, a separate Bazaar Internals manual, with a brief summary and a
pointer in an Appendix to the BUG).