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

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

2007/4/9, erik quanstrom <quanstro@coraid.com>:
> On Mon Apr  9 11:08:49 EDT 2007, devon.odell@gmail.com wrote:
> > > what do you mean by this?
> >
> > ``I don't know'' and I don't really care either. Apparently he doesn't
> > like that it takes forever and that it has the habit of wiping things
> > out sometimes. That's my understanding of his explanation, anyway.
> >
> > I'd rather not go down this thread though because I don't really want
> > to talk about why this work isn't happening, but rather what can be
> > done to make it happen and actually getting it done.
>
> rather a worked-up response for a simple question.

I didn't mean to come across as inflamed or sarcastic, rather to imply
that I don't really care what Uriel's complaints are about because
they don't address the issue. Also, my experience with this list is
that tangents like this end up going off into oblivion with no
resolution and I don't want that to happen for this issue. So again,
apologies if I seemed worked up or irritated; that wasn't the
intention.

> for the record, i think many people on this list are interested in
> fixing things.  if this is a pet project of yours, why don't you work
> on fixing it?  unfortunately, i don't have very much spare time right now.
> there are drivers to write.

I was originally trying to get Uriel to put his code where his mouth
is (or at least where it used to be). And I'm trying to work on fixing
it -- right now by analyzing what has been said and done in the past,
since this is certainly not a new `issue'. If there are already
utilities to grab diffs like this and / or a means to send diffs in
the mail, that would be an easy and ideal solution and would save time
:).

I know that discussing it to death on a mailing list is more on the
wasting time scale and if I think it starts getting to that point,
I'll just quit and write my own stuff to do it. (And to some degree, I
already am with vcs)

> i have also noticed that replica/applylog has a problem.  when i started
> experimenting with copying history from our old fileserver to the new
> one, i started using replica/updatedb and replica/applylog.  updatedb
> worked very well, but applylog hung for me pretty consistantly.
>
> my thought was that applylog has a threading deadlock, but i didn't spent
> much time thinking about it.  one thing that does help quite a bit  is to use
> replica/compactdb on your local database.  that is in /dist/replica/plan9.db.
>
> - erik

I've only just started getting into the replica code, so I'm not sure
what this would be indicative of (I'm sure your understanding is far
better than mine). 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?

--dho