[Prophesy] General questions

[Daniel Phillips]

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

The second, and carrying multiple, possibly conflicting patches forward.
Logically, this is quite difficult, but in practice we do it all the time.
So right now I'm casting around for ways of looking at the problem.

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

Here's a random link I found earlier:

   http://citeseer.nj.nec.com/context/175867/0

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

There's another, more automatic way: start with a clean tree - at the time
the SCM begins to manage it, *all* files are under management (unless told
otherwise, and there would be a list of standard exceptions such as hidden
files).  Then, every file you create, for example, with an editor or cp,
will also be managed by the SCM.  The SCM will always know when a build is
in progress (somehow), and it will not manage files created during the
build process.

If you decide to start managing a source tree that's already been built
from, then some explicit 'import' step, specifying the files to be managed,
or alternatively, those not to be managed is going to be necessary.  It
would be nice to be able to express this partitioning as an arbitrary
logical relation, to be handled by the database, it's another way to
leverage the fact that we have a full database available.

Any ideas on how we can know automatically that a build is in progress?

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

It's going to need some improving though, in order to be reliable.

-- 
Daniel