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

[Skip Tavakkolian <skip.tavakkolian@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3890 bytes --]

i was thinking more in terms of having a git client (fs) on plan9 and using
any number of public git servers. i'm looking at hgfs now; perhaps it
already does all that's needed.


On Wed, May 21, 2014 at 8:25 PM, Jeff Sickel <jas@corpus-callosum.com>wrote:

>
> On May 21, 2014, at 7:13 PM, Bakul Shah <bakul@bitblocks.com> wrote:
>
> > On Wed, 21 May 2014 09:56:26 PDT Skip Tavakkolian <
> skip.tavakkolian@gmail.com> wrote:
> >>
> >> i like git.  as it is a kind of archival file system, one should be
> able to
> >> build a plan9 file system interface for it.
> >
> > Have you looked at porting git to plan9? 178K lines of *.[ch].
> > 20K lines of shell scripts (+ 100K+ lines of test scripts).
> > Also python and perl scripts.
>
> As we’ve managed to migrate towards the topic of version control
> systems, I have to add: I don’t like git.  Maybe it’s because
> I’ve used darcs and hg so much more, or maybe it’s just that I
> don’t like the way git is used in many situations.  But mostly
> I think it’s because I’ve found that many of the github projects
> lose sight of what I think is the more important portion of
> the source history: the history and development process itself.
>
> 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.
>
> 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...
>
> 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?
>
> With a payload that large, it would take all the booster
> rockets [money] on the planet to get it into orbit.  And it
> still might break apart, fall back to Earth, and kill us in the
> process.
>
> 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.
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 4488 bytes --]