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 abil
> > 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 ker
On Thu, 22 May 2014 08:45:48 EDT erik quanstrom 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 yo
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
> 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.
> 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.
> 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
> 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
> h
> 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 exerci
> 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 gatew
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
> 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 ch
> 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. Differen
> 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.
On Thu, May 22, 2014 at 7:36 AM, 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 a
On Wednesday, May 21, 2014, Jeff Sickel 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 P
> 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
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 pro
> 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 ver
> 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
> 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
> 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 NetBS
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 wrote:
>
> On May 21, 2014, at 7:13 PM, Bakul Shah wrote:
>
> > On Wed,
On Wed, 21 May 2014 22:25:55 CDT Jeff Sickel 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 st
> 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 matte
> 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
On May 21, 2014, at 7:13 PM, Bakul Shah wrote:
> On Wed, 21 May 2014 09:56:26 PDT Skip Tavakkolian
> 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
27 matches
Mail list logo
