Re: [9fans] bell-labs website and plan9

["Devon H. O'Dell" <devon.odell@gmail.com>]

2007/4/9, Russ Cox <rsc@swtch.com>:
> devon:
> > One thing that this will need is support for a '*' target for -s (and
> > I guess for -c, too, just for consistency) to replica/applylog. I have
> > a patch for this, and I'll submit it shortly. This flag would make
> > applylog ignore all client-side (or server-side) changes, though I
> > suppose the latter is already possible.
>
> Since the arguments to -c and -s are just string prefixes, you
> can use -c '' or -s '' already.  I admit it is non-standard.

Ah, ok. I did a cursory glance over the matching code and ISTR it
using strcmp so I assumed it was a full match. In this case, I'll send
a patch for the manpage describing this (after I read it again and
determine that I didn't just miss something).

> However, you'd be better off not using replica/pull as
> the input to a differ, but instead using replica's change file
> /n/sources/plan9/dist/replica/plan9.log.  Replica(8) describes
> the format:
> [snip]
> It would be easiest to pick the two most recent dumps in
> /n/sourcesdump, diff the plan9.log files to pick out the
> new lines, and then run diffs between the two different
> dump roots.  This is what we used to do when we (I) annotated
> all the changes to produce /n/sources/extra/changes.
> But it was far too much work to do the annotations and
> not enough people cared, so we stopped that particular
> experiment.

I'll look into this. It does indeed seem to be a much more achievable goal.

> erik:
>[snip: not for me]
>
> ron:
> > My take is that bringing in mercurial, and then using mercurial with
> > mounted file systems, instead of ssh, would be quite neat. And, we are
> > close to having it. We've got python, almost. We've just about got
> > python modules -- actually, I've had them for months. Lots of bits
> > work that did not used to. We really are pretty close.
>
> Echoing Ron, I think having Mercurial would be great and doable.
> If someone makes a Mercurial client work, I will be happy to make
> a Mercurial repository that mirrors sources automatically.

Well, I prefer to not duplicate work, and the Python that I get from
Ron's website needs coaxing to build. Also, after doing that, setup.py
needed extra modules compiled in to the config. After that, it
setup.py needed the signal modules and that's when I got fed up. If
there's a Python port that builds a working python when I type `mk',
I'll start looking at it again, but I even had to edit the mkfile to
add the -x flag to 8l so it would do the dynamic linking magic.

I would be glad to work on getting this done, but I get the feeling
from Ron's postings that the code he has working is different than the
code I got from him. Ron: if you could clarify this for me, I'd really
appreciate it, because I'd definitely like to get the ball rolling on
this subject.

> Also echoing Ron, a venti-based SCM sounds similar to git,
> which is an SCM built on top of a hash-addressed object store
> (that happens not to be named venti).  It would be nice to know
> you're not reinventing git, especially since in my experience
> the fact that git is hash-addressed makes many things a lot
> harder and slower (although I am sure it has advantages).

I may be. I have never used git, and probably never will. I'm actually
trying to make something that is more similar to Perforce, but I'm not
sure that this is possible with doing what I'm doing using a vac
backend. Right now it's more experimental. If anybody would like to
use it for anything, what I currently have in
/n/sources/contrib/dho/vcs _does_ work for all intents and purposes,
it's just incomplete. However, I think 90% of the groundwork is there.

> devon:
> > In fact, I seem to recall the last time Uriel was yelling about this
> > on the list, Russ offered to do exactly this. Is this offer still
> > available? It'd save me some time and effort trying to figure out how
> > to revert a replica/pull.
>
> I put a copy of the script we used to use in
> /n/sources/contrib/rsc/makemail.  Use at your own risk.
> It probably deserves to be rewritten in a better language.

I will take a look at this.

> devon again:
> > So maybe to go further down that path (and I would
> > _love_ to get input from Bell Labs people because they're really the
> > ones that have the power to yay or nay any of this), is replica/*
> > still an ideal manner for getting updates? Are there potentially
> > better ways to do this?
>
> There are things that replica doesn't do very well.  I wish you
> could tell it to back up, or to back out local changes, and so on,
> but the core functionality works well, and I would be wary of
> falling into the CADT Model trap (ask Google).

Right, I did ask Google just now, and that makes sense. It is a valid
worry. I guess that the issue is that we currently sort of use replica
for distributing versions of our system, and, as you say below, it's
not a version control utility. More below.

> devon again:
> > The scenario being, I want to test my hypothetical replica/applylog
> > action parser / diff generator. I run pull, which grabs stuff, but
> > I've made changes to xyz.c and that file doesn't get modified because
> > of local changes. So I want to roll back my log so I can run pull
> > again with -s /sys/src/cmd/xyz.c
>
> Your thinking is stuck in the maze of twisty little passages
> that is modern Unix and its version control systems.
> Replica is a file distribution mechanism, not a version
> control system.

Well, the problem is that replica/pull won't update a file if it has
already found a conflict. (At least, I couldn't get it to earlier). I
will try re-retrieving with -s ''; I guess my question is whether I
should expect this to work. Specific example, /sys/src/cmd/ip/ping.c
was modified for my hushping patch, but pull didn't grab it because I
had modified the copy there. If I run pull again with -s '', will it
get that file this time?

However, as I said, we do use replica to keep systems `up to date', so
we do have some sort of versioned mentality in its usage. But it would
be nice to actually have some sort of SCM (hg, vcs, cvs or
what-have-you) as an option as well.

> On Plan 9, one would do this with the dump file system.
> 9fs sourcesdump and look around -- you've got all the info
> there you could possibly want to produce diffs.  You don't
> even need to copy anything to your local machine.

I'll follow your earlier advice for diff generation and take a look at
your makemail script.

> Russ

Thanks for the information; it seems rather useful.

--dho