[RFC] Why DVCS Matters

Ian Clatworthy ian.clatworthy at internode.on.net
Fri Oct 12 01:22:50 BST 2007


John Arbash Meinel wrote:
> Ian Clatworthy wrote:
>> I'm giving a paper later this year on why DVCS technology matters.
>> Elliot Murphy and Martin Pool have kindly reviewed earlier drafts but it
>> probably needs another round of changes before I'm ready to call it
>> 'final'. The latest draft is online here:
>> http://ianclatworthy.wordpress.com/2007/10/11/why-distributed-version-control-matters/.
> 
>> I'm still yet to address one of Martin's bits of feedback, namely that
>> "branch tracking scales better than patch tracking" isn't well
>> explained. Does anyone have a good reference covering that topic to save
>> me the effort? :-)
> 
> Branch tracking (as Martin is mentioning it) means that you have a single
> object (the revision id) which defines the complete ancestry.
> 
> "patch tracking" means keeping track of the set of patches that have been
> applied in this branch. Which is what Darcs (and Arch) did.
> 
> The big difference is in how things scale.

Ah. I think that just shows that I really need to explain that point
better because that's not what I meant by "branch tracking vs patch
tracking" at all. (Your point is a good one but it justifies how best to
implement a DVCS rather than why DVCS is inherently better than a
central one.)

What I meant was that keeping a list of (dumb) patches you want (e.g.
when downstream) and reapplying them when a new upstream version comes
out sucks. Far easily to do that dance by either having:

1. your own branch with patches applied and merging the new work, or

2. applying bundles with the full intelligent metadata available.

Does anyone disagree? Does anyone have any ideas on how best to explain
that if the above isn't clear enough?

Ian C.



More information about the bazaar mailing list