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.