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 <j...@corpus-callosum.com>wrote: > > On May 21, 2014, at 7:13 PM, Bakul Shah <ba...@bitblocks.com> wrote: > > > On Wed, 21 May 2014 09:56:26 PDT Skip Tavakkolian < > skip.tavakkol...@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. > > > >
