[Prophesy] General questions

[Daniel Phillips]

On Wednesday 01 May 2002 08:45, Rasmus Andersen wrote:
> Hi.
> 
> Thanks for the invite and and thanks for letting me in.
> 
> I have a number of questions that I'll list below in no apparent
> order. The list archives were not that stuffed, so I guess that
> some of the initial discussions happened prior to or outside this 
> list?
> 
> Anyway, the list:
> 
> 1) This project would seem to be a reaction to the BK thread on
>    lk and its goal (I guess) would be to get Linus off BK. So,
>    are we as a group aware/familiar with the features of BK that
>    Linus, Garzik, Riel etc, like and want? If so, could somebody
>    list them for me?

The best source of that information is the 'patch penguin' thread,
where Linus talks about starting with it, and then talks soon after
about what he wants in it.

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.

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.

> 2) In his 'Answers from 39000 ft' mail, Daniel states that prophesy
>    will manage all files in a tree. Is that convenient? If I want
>    prophesy to manage my kernel tree, I surely dont want it to
>    manage all the gunk created during a compile?

Oh no, I only meant source files.  We need a way to know what is
source and what is not.  The new kbuild makes that much easier, by
taking all the generated files out of the tree.  This still leaves
questions about configuration-generated symlinks, which should not
fool the SCM into thinking there are more files than there really 
are.

> 3) Are anybody on this list familiar with SCM? More to the point,
>    could anybody here give me a list of SCM related links/infor-
>    mation? Weave vs. diff+patch(xdelta)? How to merge sanely/
>    automagically?

I'm not 100% clear on 'weave' yet myself.  Soon will be though:

  http://www.perforce.com/perforce/life.html

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

> 5) Daniel's 39K mail didn't mention changesets, the ability to
>    group changes to files. I guess we are going to have this?
>    And changesets would be on a delta-commit basis? (These may
>    be too concrete for now, answer at will :)

Yes.  I'm trying to avoid steering too close to Larry's terminology
just for now, until I understand how standard it is.  For now, a
'delta' to me, is the difference between any two source trees, and
deltas can be partitioned into things called... I don't know,
subdeltas or something, the relationship being, and subdeltas can
also be partitioned.  Not only that, but the partitioning of
subdeltas is fluid, and can be changed using database queries, such
as 'select all the files that satisfy this logical expression, and
the delta will be partitioned into the part that affects those
files and the part that doesn't'.  Or logical tests could be applied
at the line level, and so on.  We want to really leverage the fact
that we can put a full-blown sql database into the mix, that's
something the proprietary side would have a lot of trouble doing.

> 6) Tom Lord's 'arch' have been mentioned as an alternative for
>    BK. Are we aware of how he handles some of the above questions?
>    (All these aware/familiar questions are really disguised
>    versions of 'I dont know. Please tell me about X if you know.')

No, and I swear I will try it this weekend!

> 7) Why is this a closed list?

It was the decision of the gentleman who set it up, or perhaps it was
an accident.  Considering the recent flamewar, I don't think it's
wrong to keep it closed for the time being.

-- 
Daniel