[Prophesy] General questions

[Rasmus Andersen]

On Fri, May 03, 2002 at 10:42:27PM +0200, Daniel Phillips wrote:
> > 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.

I'm not quite following you here. I thought BK allowed you to have a
number of patches/changes in a tree, update the tree (from Linus)
and have the changes carried forward?

Or are you talking about carrying a selected patch set forward across 
multiple tree versions?

Or am I just not getting you? :)

> > 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.

If you find literature, do share. I'll do my best to get acquainted
with some of these tools as well.

[distributed discussion]
> 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.

Agreed on both points.

> 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.

Agreed on the design rule. 

> 
> 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?)

While we may make our lives a bit easier coupling the SCM tightly to
the kernel, lets not pretend that we magically get a well-controlled
build environment. E.g., kbuild 2.5 lets you build objects in the
source tree and somewhere somebody actually have a good reason for
doing that. My point: If we make crass assumptions like that, we
will get flamed.

But we could easily go for the 'normal' SCM angle of attack: Have
the user say 'these files' or 'this directory'. We could the also
offer 'all files in this dir for ever'.

> 
> 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.

Yes, dnotify is an elegant way to notice this.

Rasmus