5. Represent merges. That's what is making cvs branches unusable.
Frankly, if you want all of that you'd better design a repository
format that is actually adapted to it. The RCS format is not very
good, the SCCS weave is a little better but not by much (it reminds me
of Hurd, looks cool but slow by design). Larry did quite a feat
turning it into a distributed DAG of versions but I'm not convinced it
was that smart, technically. In particular, everthing suddendly looks
much nicer when you have one file per DAG node plus a cache zone for
But anyway, what made Bitkeeper suck less is the real DAG
structure. Neither arch nor subversion seem to have understood that
and, as a result, don't and won't provide the same level of semantics.
Zero hope for Linus to use them, ever. They're needed for any
decently distributed development process.
Hell, arch is still at the update-before-commit level. I'd have hoped
PRCS would have cured that particular sickness in SCM design ages ago.
Atomicity, symbolic links, file renames, splits (copy) and merges (the
different files suddendly ending up being the same one) are somewhat
important, but not the interesting part. A good distributed DAG
structure and a quality 3-point version "merge" is what you actually
need to build bk-level SCMs.
 2.1.6-pre5, I don't know about current versions
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/