From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <9ab217670704090918x313c4f0dr6476bbe7e1e66590@mail.gmail.com> Date: Mon, 9 Apr 2007 12:18:43 -0400 From: "Devon H. O'Dell" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] bell-labs website and plan9 In-Reply-To: <20070409155043.6EC651E8C1F@holo.morphisms.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9ab217670704090750h19fd808dw171a046d088df5f@mail.gmail.com> <20070409155043.6EC651E8C1F@holo.morphisms.net> Topicbox-Message-UUID: 42432746-ead2-11e9-9d60-3106f5b1d025 2007/4/9, Russ Cox : > 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