[Prophesy] General questions

[Daniel Phillips]

On Friday 03 May 2002 22:15, Rasmus Andersen wrote:
> (I'm just back from business travel and is quite bombed, so this
> is even terser than usual.)

Terse is good.

> > I'd see it being useful to other people way before being attractive
> > enough to Linus to break his BK habit.  I've noticed that I personally
> > am spending far more time fiddling around creating and maintaining
> > patch sets than I should, so... if I invested that time in getting
> > some tools together instead of messing with the patch it would be a
> > win already.
> 
> Perhaps you could explain a bit more here? This seems like something
> we could work into an advantage.

Yes.  I'd like to somehow turn a 'patch' into an object managed by the
SCM system.  So you'd carry not just multiple tree versions, but multiple
patches forward, the way real live developers do.  Since developers do it,
it must be possible to automate.  But every SCM I've looked at so far
takes a view of the whole tree, a history of commits to it, and a tree of
forks.  That is somehow not the whole story  There is, in reality, much
more structure to parallel development than that.

> > The *immediate* purpose of this is to provide a repository that the
> > patchbot can operate and that Linus can pull from, and which is not
> > Bitkeeper.
> 
> If immediacy is a goal, then there is working code out there
> already... But you know that.

Right, and ignoring it would be silly.  I'm working with BitKeeper now,
Arch and Subversion are on my list, I'm looking at some of the power
features of CVS, and looking at the literature.  But mainly, I'm thinking
about things from first principles as is my habit.

More on that later.

> > > 4) One of the features from 1) would be the distributed nature
> > >    of BK, I guess? Are there any thoughts on how to handle this?
> > 
> > I thought I'd first think about having it work very well, locally.
> > We don't need it to be distributed for either of the first two
> > applications, that is, preparing patch sets and acting as a
> > repository for the patchbot.  Or, another way of putting that is,
> > Larry already provides us a way for it to be distributed, through
> > his pull.  And no, I haven't thought at all about how technically
> > difficult it will be to support a BK pull yet.  There might even
> > be legal questions of whether Larry's patents allow us to support
> > a BK pull, and if so... then I think we'll suddenly find a lot
> > more developers on the project, so that possibility doesn't worry
> > me.
> 
> One problem is that making something distributed sucks if the
> initial design dont't allow for it.

No question about that.  Now, I've done just enough BitKeeping to know
that, even though it's designed for distributed operation from the
beginning, it still kind of sucks at it.  For one thing, if somebody is
cloning, the whole repository is locked for the duration - any push to
the repository has to wait.  So much for elegance.

My strategy is: first propose the functionality, then see how it can be
distributed, without making any compromise to the local functionality.
Doing the whole design around distributed operation and then having to
apologize for nonintuitive behavior on the user side sucks too.

Another thing about BitKeeper: you have to do 'bk edit' before you edit,
otherwise, if you just chmod +w the file and edit away, it gets screwed
up, with no intelligible error messages.  Stupid.  Also, bk co and bk ci
are just stupid wastes of time, in my opinion.  The number one design
rule as far as I'm concerned is: you can edit your repository just like
a normal source tree.  It looks and acts just like a normal source tree.
The SCM takes care of the details for you.

Now... how to make that work.  First problem, how can the SCM tell the
difference between generated files and source files?  Should we just
give it a list of files to ignore, as for patch?  Is there a more
elegant way, perhaps in conjunction with the new kbuild code?  (And then,
how tied to the kernel is kbuild, and do we care about managing source
besides the kernel?)

As far as knowing what files the user is editing, and when to update the
SCM's db, we will use Linux's dnotify mechanism for that.  This part of
the design is under control I think, I'll provide a writeup in due course.

-- 
Daniel