[RFC] Why DVCS Matters

John Arbash Meinel john at arbash-meinel.com
Thu Oct 11 15:58:35 BST 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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. Say you have two branches of a very
old project. And you want to know what revisions (patches) are missing. In a
DAG system, you start looking at the tips and work backwards. Once you have
entries in common, you know you have all ancestors in common, so you can stop
looking. In a "patch tracking" the missing revision could be any ancestor. So
you have to look at the full ancestry.

So "patch tracking" generally always scales by O(history) (and thus gets slower
and slower the older your project is). I *think* darcs works around this by
just setting a patch horizon. Such that you just can't inspect the history
before that. But I'm not sure how that plays with their "theory of patches".


> 
> I'm also thinking that the topic of migration (e.g. bzr-svn, tailor,
> etc.) isn't covered at all and probably needs to be, at least briefly.
> The paper is up to 7 papers and a maximum of 5 pages was recommended so
> I've currently left that out. Part of my thinking re dropping it is that
> migration technology is very much a moving target and best practice
> arguably depends a lot on source and target tools. Is it acceptable to
> leave migration issues out altogether? If not, what points are important
> to make?

It might be worthy to mention the idea of migration technologies. But certainly
that is a whole paper in itself. :)

> 
> If I'm missing references to important articles on the technology,
> please also let me know. As best I know of, this is one of the few
> papers that attempts to address the "why should I care when I'm happy
> using central VCS" question as comprehensively as this. Given that, I'm
> doubly keen to ensure it's actually factual, clear and useful to others.
> 
> Ian C.
> 
> 

I'll try to give it a look over.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHDjobJdeBCYSNAAMRAqv3AJ9vHSR8Wl2yukv7P/GtSK5HYBS/1gCeI3Uc
80XF/3NzCfNAWe4Nm1C80ac=
=qiy3
-----END PGP SIGNATURE-----



More information about the bazaar mailing list