public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Larry McVoy <lm@bitmover.com>
Cc: Roger Gammans <roger@computer-surgery.co.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: using bitkeeper to backport subsystems?
Date: 23 Jul 2002 12:38:54 -0600	[thread overview]
Message-ID: <m1y9c2mgqp.fsf@frodo.biederman.org> (raw)
In-Reply-To: <20020722154443.E19057@work.bitmover.com>

Larry McVoy <lm@bitmover.com> writes:

> On Mon, Jul 22, 2002 at 11:29:41PM +0100, Roger Gammans wrote:
> > On Mon, Jul 22, 2002 at 08:20:31AM -0700, Tom Rini wrote:
> > > Possibly, once bitkeeper allowes ChangeSets to only depend on what they
> > > actually need, not every previous ChangeSet in the repository.  IIRC,
> > > this was one of the things Linus asked for, so hopefully it will happen.
> > 
> > While that would be great.
> > 
> > With all due respect to Larry and the bk team, I think you'll
> > find determining 'needed changesets' in this case is a _hard_ problem.
> 
> Thanks, we agree completely.  It's actually an impossible problem
> for a program since it requires semantic knowledge of the content
> under revision control.  And even then the program can get it wrong
> (think about a change which shortens the depth of the stack followed by
> a change that won't work with the old stack depth, now you export that
> to the other tree and it breaks yet it worked in the first tree).

Perfection is impossible.  However there is a lot of independent code
in the linux kernel.  It has to be that way or maintenance would quickly
become impossible.  

The last time this was suggested, the idea was to look how far back into
the repository  (up to a given limit) a current changeset could apply, with all
of it's current dependencies. 

But beyond that I suspect it would be easier to declare lack of dependencies.

drivers/net and drivers/ide are completely separate subtrees.  At
least not until you get ATA over ip.  And even then the dependencies
is with the ip layer.  

Maybe independence should be shown by putting each independent chunk
into it's own repository.  And then building a working kernel tree 
would just be a matter of checking out all of the parallel
repositories, into the appropriate location.  Then the global tree
can just remember which version of all of the subtrees it was
tested with last.

Given that a fully independent program is likely to break because of
a buggy libc (which I have no business depending upon the exact
version), I think the insistence on global dependencies is just plain
silly, you can never find the entire set of dependencies.  

So Larry please cope with the fact that perfect dependency modeling is
impossible, and setup a method that works in the real world.  Or do
you have a way to model that my code only works on a magic test
machine, that magically catches a page fault, and does the right
thing, while all other machines page fault reliably?

Eric

  parent reply	other threads:[~2002-07-23 18:47 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-21 23:34 using bitkeeper to backport subsystems? Andreas Schuldei
2002-07-22  7:15 ` Val Henson
2002-07-22  8:29   ` Christoph Hellwig
2002-07-22 10:27     ` Andreas Schuldei
2002-07-22 10:29       ` Christoph Hellwig
2002-07-22 15:25         ` Larry McVoy
2002-07-25 21:48           ` Andreas Schuldei
2002-07-22 15:20       ` Tom Rini
2002-07-22 22:29         ` Roger Gammans
2002-07-22 22:44           ` Larry McVoy
2002-07-23  8:16             ` Lars Marowsky-Bree
2002-07-23 18:38             ` Eric W. Biederman [this message]
2002-07-23 22:46               ` Larry McVoy
2002-07-22 10:43     ` Thunder from the hill
2002-07-22 10:46       ` Christoph Hellwig
2002-07-22 11:02         ` Thunder from the hill
2002-07-22 11:03           ` Christoph Hellwig
2002-07-22 13:45         ` Mark Mielke
2002-07-22 13:48           ` Christoph Hellwig
2002-07-22 17:52     ` Val Henson
  -- strict thread matches above, loose matches on Subject: below --
2002-07-23 14:31 Matthias Urlichs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1y9c2mgqp.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm@bitmover.com \
    --cc=roger@computer-surgery.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox