Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]

[Bakul Shah <bakul@bitblocks.com>]

On Wed, 21 May 2014 22:25:55 CDT Jeff Sickel <jas@corpus-callosum.com> wrote:
> At the base level I find that sources and sourcesdump are much
> more accessible than many of the DSCMs (e.g., darcs, git, hg)
> out there.  Yes it's great to use hg to snapshot state and
> allow easy migration across various systems, but it still
> clutters the model.

Wouldn't something like cinap's hgfs give you the same thing?

> One of the advantages of having a real archival store, like
> Venti, is that it changes the conceptual level of how you deal
> with metadata about a project.  When the default is everything
> is saved and you can manipulate the namespace to represent
> various portions of the history then you don't get caught
> up in all the branching, rebasing, queues, merges, and other
> general contortions that would make us happy to warp back in
> time to an early copy of Dr. Dobb's Journal of Computer
> Calisthenics & Orthodontia when the future looked bright and
> we really could do anything with 8 bits.  Sure working with
> an automatic snapshot system can be a headache at times, but
> it's one of those that easily passes, not like sitting down for
> a [git] root canal because your tooth has been rotting to the
> core while you worry about the configuration for the hottest
> continuous integration system with a butler name that shows we
> really didn't learn anything about the 18th or 19th century
> transitions to the modern age...

Branch/merge features evolved in response to people's needs.
Merging is necessary if you (as an organization) have
substantial local changes for your product (or internal
use) and you also want to use the latest release from your
vendor. No amount of namespace manipulation is going to
help you. Parallel development is inherently more headachy!

> Back on topic: be careful of the dependencies required to
> get a system bootstrapped.  The FreeBSD community took BIND
> out of the default system and re-wrote a new basic resolver
> because the BIND 10+ versions would require packaging Python
> into the core distribution.  There's no reason for
> bringing in more than is necessary to build, and putting a
> dependency on Python would significantly increase the build
> time and total lines of code to maintain just to have hg.
> Darcs is in the same boat in that you'd have to keep a version
> of Haskell in the system.  Git is the closest as it's just C,
> sort of: it's a whole lot of code.  But why would you want to
> bring in "178K lines of *.[ch], 20K lines of shell scripts, 100K+
> lines of test scripts" and have to lug in the massive payload
> of Python and Perl just to make it functional?

I was certainly not suggesting porting git to plan9!  Just
pointing out how painful and big the task would be -- I was in
fact saying use hg!

I looked at a few alternative and felt hg is the only workable
alternative that is usable right now.

A dependency on python doesn't seem much worse than one on
ghostscript. Neither should be built every time you do `mk all'
in /sys/src but it should be possible to build them. And at
least python would be much more useful than gs!

Though the idea of a scmfs (for checkins as well) and using
vac/venti as a backend is starting to appeal to me : )

> At the end of the day, it's the communication with people that's
> the largest benefit.  Let's continue building systems based on the
> ideas that drew us all to Plan 9 in the first place.

Well, nothing prevents us from continuing to use the existing
system.