Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
Ok, My take on VCS/SCM and fossil+venti you can copy the repository to a working copy with - dircp. you can tag a release with - dircp (don't forget, copying a directory set is very nearly free in terms of disk space). adding a log message is cat ChangeLog the only bit missing is the ability to freeze (seal) a tagged version. You need the ability for users in a special dumpers group to be ablc to take archival snapshots on demand. merge can be done using diff3 from ed7 (in my contrib), though this is a bit clunky. a real graphical merge tool would be great (exercise for the reader ☺) -Steve
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
On Thu, 22 May 2014 07:36:54 +0200 lu...@proxima.alt.za wrote:
Though the idea of a scmfs (for checkins as well) and using
vac/venti as a backend is starting to appeal to me : )
Let's open the discussion, Plan 9 has some baseline tools other OSes
are still thinking about and will probably implement stupidly. Since
RCS I've been thinking that there has to be a better way and CVS went
a long way to satisfy my personal requirements. Now may well be the
time to look at fresher options.
I am attaching an excerpt from an old email (May 26, 2011)
that I never sent. These ideas are not even half baked. But
may be they will trigger some creative thoughts.
On Thu, 26 May 2011 20:16:11 EDT erik quanstrom quans...@quanstro.net wrote:
file servers are great, but hg concepts aren't really file-system oriented.
it might be nice to be able to
diff -c (default mybranch)^/sys/src/9/pc/mp.c
but hg diff figures out all the alloying stuff, like the top-level of the
repo anyway. also, ideas like push, pull, update, etc., don't map very well.
so a hg file server seems to me a bit like, have hammer, see nail.
I thik the filesystem model is more like an electric motor
that powers all sorts of things given the right attachments!
if i'm missing why this is an interesting idea, i'd love to know what
i don't see.
I partially agree with you; hence the suggestion about editor
integration.
It is just that I have wondering about just how far the FS
model can be pushed or extended seamlessly in various
directions.
In the context of SCMs, we can map a specific file version to
one specific path -- this is what hgfs above does. But what
about push/pull/commit etc.? One idea is to to map them to
operations on magic files.
For example,
- local file copies appear as normal files.
- cat .hg/status == hg status
- cat .hg/commit == hg commit
- cat .hg/log == hg log
- echo -a .hg/revert == hg revert -a
- echo $url .hg/push == hg push $url
- echo $url .hg/pull == hg push -u $url
- ls .hg/help
- cat .hg/help/push
In fact the backend SCM need not be mercurial; it can git,
venti etc. Can we come up with a minimal set of features?
Do we gain anything by mapping $SCM commands to special files?
The same question can be asked about many of existing plan9
filesystems. At least for me visualizing new uses is easier
when more things can be fitted in a simpler model.
Features such as atomic commits, changesets, branches, push,
pull, merge etc. can be useful in multiple contexts so it
would be nice if they can integrated smoothly in an FS.
Example uses:
- A backup is nothing but a previous commit. A nightly
backup cron job to do echo `{date} .commit
- an offsite backup is a `push'.
- Initial system install is like a clone.
- An OS upgrade is like a pull.
- Installing a package is like a pull (or if you built it
locally, a commit)
- Uinstall is reverting the change.
- Each machine's config can be in its own branch.
- You can use clone to create sandboxes.
- A commit makes your private temp view permanent and
potentially visible to others.
- Conversely old commits can be spilled to a backup
media (current SCMs want the entire history online).
- Without needing a permanent connection you can `pull' data.
[never have to do `9fs sources; ls /n/sources/contrib'.]
A better integration can inspire new uses:
- a timemachine like a gui can help quickly scroll through
changes in some file (or even a bird's eye view of changes
in all the files).
- combining versioning + auto push/pull with other filesystems
can open up new uses. You can keep your own daily archive of
http://nyt.com/ or see how a story develops by scrolling through
changes.
Just some things I was mulling about. As you can see there are
lots of open questions half-baked ideas to sort through.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
I am attaching an excerpt from an old email (May 26, 2011) that I never sent. These ideas are not even half baked. But may be they will trigger some creative thoughts. I was hoping for this type of interest, I'm very pleasantly surprised that it now seems to be materialising. I guess I'll need to track this discussion on google groups now, ACME mail is a bit limited in this regard (and probably also needs to be enhanced both for discussions like this one and for code review purposes), L += 1
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
On Wednesday, May 21, 2014, Jeff Sickel j...@corpus-callosum.com wrote: 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? In case anyone is _really determined_ to do this: libgit2 has only 117K lines of code, better than git's 178K. It also has a mere 200 lines of shell, total. It doesn't depend on Python or Perl. It's also supposed to be much more portable than git, though I dunno if that would actually work out for Plan 9. Probably not that much. You could try porting libgit2 and then write some small C wrappers using it.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
On Thu, May 22, 2014 at 7:36 AM, lu...@proxima.alt.za wrote: (I dislike that Go comes with C compilers and assemblers that seem to be heading off into the hills - our little group of Go porters (please forgive me for presuming) ought to be addressing this issue as well) What issues? What are you talking about? -- Aram Hăvărneanu
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
What are you talking about? Merely that it would be nice if 8c on Plan 9 was the same utility, whether Go is installed or isn't. I'm not expecting it to just happen, but I do think it would be better than what we have now. L.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
Merely that it would be nice if 8c on Plan 9 was the same utility, whether Go is installed or isn't. I'm not expecting it to just happen, but I do think it would be better than what we have now. And what would be the benefit of that? Plan 9's 8c and Go's 8c are different programs. Different calling conventions, different output. Right now Go's 8c uses liblink and generates machine code. .8 files cannot be consumed by Plan 9's 8l. Even before liblink there were serious incompatibilities in the object files. 8c is going away soon anyway, after 8g is rewritten in Go. -- Aram Hăvărneanu
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
Features such as atomic commits, changesets, branches, push, pull, merge etc. can be useful in multiple contexts so it would be nice if they can integrated smoothly in an FS. - Installing a package is like a pull (or if you built it locally, a commit) - Uinstall is reverting the change. - Each machine's config can be in its own branch. what is the advantage over seperate files? imo, this complicates the issue. - You can use clone to create sandboxes. - A commit makes your private temp view permanent and potentially visible to others. - Conversely old commits can be spilled to a backup media (current SCMs want the entire history online). - Without needing a permanent connection you can `pull' data. [never have to do `9fs sources; ls /n/sources/contrib'.] this is a nice list, but i think a key point is not being teased out. the dump file systems are linear. there is a full order of system archives. in hg, there is a full order of the tip, but not so of branches in general. in git, multiple orders (not sure if they're full or not) can be imposed on a set of hashes. another key point is that all distributed scms that i've used clone entire systems. but what would be more interesting is to clone, say, /sys/src or some proto-based subset of the system, while using the main file system for everything else. imagine you want to work on the kernel, and imagine that you keep console log files. clearly you want to see both the new log entries, and the modified kernel. i would be concerned that this really challenges the plan 9 model of namespaces. one would have to figure out how to keep oneself out of namespace hell if one were to build this into a file system and use it heavily. - erik
[9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
I would throw in a vote in favor of a good git client. It's something I use daily and I find it works well with distributed people working on the same project. Which is a situation Linux and plan9 share. Last time I looked at how it was put together the 'core' was actually just a small handful of commands most of which where implementing the content addressed filesystem (that git essentially is). All the other commands just built on top of those basic ones to implement handy features or more user friendly-ness. As suggested above I also think git should fit reasonably well with plan9's filesystem interface. To continue throwing out half-baked ideas. I would envision something like: cp /usr/glenda/myproject /n/git/staging ##Add project files to staging echo Add new feature X /n/git/commit ###Commit staging directory with message cat /n/git/log # view all logs echo 34nb432 /n/git/log ###Tell it you want to read log 34nb... cat /n/git/log ###Reads out log selected with previous command echo my-git-repo.example.com:HEAD /n/git/pull ###Pull changes from online repo Of course, as git just wants another .git directory that could just as easily be echo /n/sources /n/git/pull ###Pull changes to sources If it was decided that someone might like to try to port git I'd imagine you could just port the basic boiler plate commands, and a few higher level ones, ignoring the fancy util commands like bisect that are unlikely to be needed often and tackle those as-needed. But that comment could stand some verification. http://git-scm.com/book/en/Git-Internals-Plumbing-and-Porcelain is an interesting read if anyone is interested.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
More seriously, though, on the issue of revision control on Plan 9 (and code review, that being the really important aspect) I'd like us to keep in mind that being able to interface with existing repositories, difficult as it may be, would be greatly beneficial. To like i said, a hg gateway hosted on google code or whatever is for me welcome, but that's not my top priority. if it is your top priority, then go to it. if you need some system changes, submit patches. if they're invasive, it might be good to discuss the plan first in public. - erik
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
That said, let me add my encouragement to sample apatch as suggested by Erik, although any valid objections ought to be raised here. One, from me, comes from Erik himself a modified version of Nemo's (a)patch (I don't have the exact quote handy. Nemo, could we please start this exercise with one, and only one version of this? the original version is, as far as i know, no longer in use. i only mentioned the lineage to credit nemo with the work. - erik
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
Go is in a different league: Heretical as it may seem, we can generate Go binaries without compelling all Plan 9 installations to include the Go toolchain, no matter how valuable some of us may perceive it. HG without Python is a dead rat. that's a partially binary distribution. a proper, full, distribution would have the same issue. and go introduces new issues, it's much more in flux than python. the risk is that a go update could then break the system. and only runs on 386. it does not run on plan 9 mips, arm, or amd64. - erik
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
the original version is, as far as i know, no longer in use. i only mentioned the lineage to credit nemo with the work. Out of curiosity, what prompted not using CVS? I can think of a number of reasons, but none that echo with your comments up to now. L.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
and go introduces new issues, it's much more in flux than python. the risk is that a go update could then break the system. and only runs on 386. it does not run on plan 9 mips, arm, or amd64. These are very valid reservations, I hadn't thought of them. L.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
On Thu May 22 09:45:08 EDT 2014, lu...@proxima.alt.za wrote: the original version is, as far as i know, no longer in use. i only mentioned the lineage to credit nemo with the work. Out of curiosity, what prompted not using CVS? I can think of a number of reasons, but none that echo with your comments up to now. cvs wasn't considered because it's not appropriate. the 9atom model is single committer. very much like linus' model. - erik
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
On Thu, 22 May 2014 08:45:48 EDT erik quanstrom quans...@quanstro.net wrote: Features such as atomic commits, changesets, branches, push, pull, merge etc. can be useful in multiple contexts so it would be nice if they can integrated smoothly in an FS. - Installing a package is like a pull (or if you built it locally, a commit) - Uinstall is reverting the change. - Each machine's config can be in its own branch. what is the advantage over seperate files? imo, this complicates the issue. I don't quite recall what I was thinking 3 years ago in a 30 minute window but I think the idea was that you have a set of configuration files which all need to be consistent and if you wanted to roll back changes, you'd have to undo all those changes. - You can use clone to create sandboxes. - A commit makes your private temp view permanent and potentially visible to others. - Conversely old commits can be spilled to a backup media (current SCMs want the entire history online). - Without needing a permanent connection you can `pull' data. [never have to do `9fs sources; ls /n/sources/contrib'.] this is a nice list, but i think a key point is not being teased out. the dump file systems are linear. there is a full order of system archives. in hg, there is a full order of the tip, but not so of branches in general. in git, multiple orders (not sure if they're full or not) can be imposed on a set of hashes. So if we do SCM right, backups are just a subset, right?! No, don't believe that. No time to explore this right now but I think dumps are at a different (lower) level from SCM data. another key point is that all distributed scms that i've used clone entire systems. but what would be more interesting is to clone, say, /sys/src or some proto-based subset of the system, while using the main file system for everything else. imagine you want to work on the kernel, and imagine that you keep console log files. clearly you want to see both the new log entries, and the modified kernel. Actually with something like venti as the store, `clone' is trivial! Just find the hash for a particular changeset you want to clone and you can build the rest on demand. `rebase' or `pull' will be more painful. i would be concerned that this really challenges the plan 9 model of namespaces. one would have to figure out how to keep oneself out of namespace hell if one were to build this into a file system and use it heavily. Your concern is a bit premature. We are just handwaving right now! I am interested in finding out just how far we can push the plan9 model -- and if the current model doesn't naturally fall out of any extended model, we'd know.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
another key point is that all distributed scms that i've used clone entire systems. but what would be more interesting is to clone, say, /sys/src or some proto-based subset of the system, while using the main file system for everything else. imagine you want to work on the kernel, and imagine that you keep console log files. clearly you want to see both the new log entries, and the modified kernel. Actually with something like venti as the store, `clone' is trivial! Just find the hash for a particular changeset you want to clone and you can build the rest on demand. `rebase' or `pull' will be more painful. venti is going to be a difficult model. the objects in scm are typically arbitrarly sized, and have arbitrary metadata. θfs has this model for its object store. venti does not. i would be concerned that this really challenges the plan 9 model of namespaces. one would have to figure out how to keep oneself out of namespace hell if one were to build this into a file system and use it heavily. Your concern is a bit premature. We are just handwaving right now! I am interested in finding out just how far we can push the plan9 model -- and if the current model doesn't naturally fall out of any extended model, we'd know. i don't know. this concern was addressed in the very first paper, and i have delt with some plan 9-based systems that did this, and didn't get it right. but it can be addressed without much trouble. just have the fs export em all. - erik
[9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
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.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
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. Thank you for the opened door, Jeff :-) I've been mulling revision control (actually, strictly source control, I have little interest in patching binaries, no matter what old tin can they are fitted with[1]) and one novel idea that keeps nagging me without quite settling in my head is the use of Plan 9's proto to record at least part of the history. Is this entirely original of me? Is it totally insane, or is there perceived merit in what my subconscious keeps shouting at me? ++L [1] See the original cover of Mike Oldfield's Tubular Bells
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
putting a dependency on Python would significantly increase the build time and total lines of code to maintain just to have hg. Go is in a different league: Heretical as it may seem, we can generate Go binaries without compelling all Plan 9 installations to include the Go toolchain, no matter how valuable some of us may perceive it. HG without Python is a dead rat. All for Bind in Go, raise both hands :-) ++L
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
On Wed, 21 May 2014 22:25:55 CDT Jeff Sickel j...@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.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
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.comwrote: 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.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
I looked at a few alternative and felt hg is the only workable alternative that is usable right now. I'm going to stand right with Bakul on this. The actual reasons are not technical, but they are sound. I don't want to install Python on my Plan 9 equipment, but I have HG on Ubuntu and NetBSD to provide the services I need. I also have no idea if this is viable for a mixture of Plan 9 and Windows, exclusively, I avoid Windows and I'm trying to move away from Linux and Android (yes, same thing, indeed). That said, let me add my encouragement to sample apatch as suggested by Erik, although any valid objections ought to be raised here. One, from me, comes from Erik himself a modified version of Nemo's (a)patch (I don't have the exact quote handy. Nemo, could we please start this exercise with one, and only one version of this? ++L
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
And at least python would be much more useful than gs! I disagree. I try to use Plan 9 to display PDFs as much as it is able to. When it fails, I resort to whatever my recent version of Ubuntu supports. ++L
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
Though the idea of a scmfs (for checkins as well) and using vac/venti as a backend is starting to appeal to me : ) Let's open the discussion, Plan 9 has some baseline tools other OSes are still thinking about and will probably implement stupidly. Since RCS I've been thinking that there has to be a better way and CVS went a long way to satisfy my personal requirements. Now may well be the time to look at fresher options. I'd like to throw Go into the picture because I have more or less sold my soul to that devil, but I'm willing to continue using C (I dislike that Go comes with C compilers and assemblers that seem to be heading off into the hills - our little group of Go porters (please forgive me for presuming) ought to be addressing this issue as well) if the community feels strongly about it. L += 1 PS: I've dropped ++ from the list of operators I use in Go. I see no value in this operator that the more explicit form += 1 does not satisfy better. Please do show me how I'm mistaken.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
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. A git client would be good. When I attempted to install git on NetBSD I ran into trouble because the packaged version (even if compiled from sources) demanded the X development system to be installed (I need to run this by the NetBSD folk, but it hardly matters). I in fact now use Ubuntu to fetch git stuff and the seamlessness of the Go tool goes out the window. The Plan 9 side of this is really for discussion in the Go forum(s), but perhaps others here would care to comment? More seriously, though, on the issue of revision control on Plan 9 (and code review, that being the really important aspect) I'd like us to keep in mind that being able to interface with existing repositories, difficult as it may be, would be greatly beneficial. To what degree one bends over backwards to be compatible is a separate discussion, to be had about the merits of each system. But the underlying system must not preclude the option. L += 1
