public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: torvalds@transmeta.com (Linus Torvalds)
To: linux-kernel@vger.kernel.org
Subject: Re: 2.5 changeset 1.952.4.2 corrupt in fs/jfs/inode.c
Date: Wed, 5 Feb 2003 22:09:56 +0000 (UTC)	[thread overview]
Message-ID: <b1s23k$3je$1@penguin.transmeta.com> (raw)
In-Reply-To: 20030205205127.GP19678@dualathlon.random

In article <20030205205127.GP19678@dualathlon.random>,
Andrea Arcangeli  <andrea@suse.de> wrote:
>
>What I care is how can I find the order of the changesets that are
>applied to Linus's tree? That's all I need to know. I thought the order
>shown on the web would just provide this information, but now I'mlost...

You are lost because no such simple order exists.

You're trying to force a partially ordered set (BK changesets) into a
strictly ordered set (CVS-like thing), and you can't do it.

Assuming a static BK tree, you can always find _one_ ordering that will
work. But when the next merge comes around, you'll notice that you may
well have to re-order. You can never get it right.

The fact is, a BK tree is fundamentally more powerful than a linear CVS
tree. If you want to get the BK information into CVS, you have to
either:

 - throw away information (every time I do a merge, you commit all the
   new code as one patch or possibly a set of "linearized" patches at
   the top-of-tree)

 - you use a CVS branch/merge to emulate every non-linear BK event (and
   you'll probably have to rebuild the whole CVS tree every time a merge
   occurs)

>Also note that the fact changesets can be merged in the past, and not
>alwayas in the head

No.  ChangeSets _cannot_ be merged in the past.  ChangeSet's can be
_based_ on past events, and have times in the past, and be merged
through a to the top of tree.

I don't think you can emulate this in CVS easily, since the branch has
to be "pre-created" in the CVS repository (when it was HEAD), I don't
think you can go back and create a branch "in the past" to graft onto. 
Which is why I think you have to recreate the whole CVS tree (and insert
the branch point at the right point) when this happens in order to
really get the full BK information. 

So please realize that BK is different from (and strictly more powerful
than) CVS.  But this difference is the whole _point_ of it, and the
reason for why I use it for the kernel, and refuse to use CVS. 

			Linus

  reply	other threads:[~2003-02-05 22:03 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-05 17:40 2.5 changeset 1.952.4.2 corrupt in fs/jfs/inode.c Andrea Arcangeli
2003-02-05 18:23 ` Andrew Morton
2003-02-05 18:45   ` Andrea Arcangeli
2003-02-05 19:42     ` Dave Jones
2003-02-05 20:06       ` Andrea Arcangeli
2003-02-05 19:43     ` Andrew Morton
2003-02-05 19:51       ` Andrea Arcangeli
2003-02-05 20:09         ` Andrew Morton
2003-02-05 20:18           ` Andrea Arcangeli
2003-02-05 20:33             ` Andrew Morton
2003-02-05 23:29         ` Larry McVoy
2003-02-05 20:11       ` Matt Reppert
2003-02-05 20:24         ` Andrea Arcangeli
2003-02-05 20:56           ` Linus Torvalds
2003-02-05 20:25         ` Linus Torvalds
2003-02-05 23:31         ` Larry McVoy
2003-02-05 23:37           ` Christoph Hellwig
2003-02-05 23:57             ` Larry McVoy
2003-02-06  0:22               ` Robert Love
2003-02-06 16:58               ` Andreas Dilger
2003-02-06 17:30                 ` Larry McVoy
2003-02-06 17:55                   ` Matt Reppert
2003-02-07 16:18                     ` glibc-2.3 [Was: Re: 2.5 changeset 1.952.4.2 corrupt in fs/jfs/inode.c] Horst von Brand
2003-02-07 18:06                       ` Larry McVoy
2003-02-06  0:37           ` 2.5 changeset 1.952.4.2 corrupt in fs/jfs/inode.c Chris Funderburg (at home)
2003-02-06  0:45           ` Alan Cox
2003-02-05 23:51             ` Larry McVoy
2003-02-06  0:02               ` Mitch Adair
2003-02-06  0:08                 ` Larry McVoy
2003-02-06 10:02           ` Nick Craig-Wood
2003-02-09 18:37             ` Kenneth Johansson
2003-02-05 19:46 ` Sam Ravnborg
2003-02-05 20:04 ` Dave Kleikamp
2003-02-05 20:10   ` Andrea Arcangeli
2003-02-05 20:16     ` Dave Kleikamp
2003-02-05 20:34     ` Sam Ravnborg
2003-02-05 20:51       ` Andrea Arcangeli
2003-02-05 22:09         ` Linus Torvalds [this message]
2003-02-06 10:46           ` Roman Zippel
2003-02-06 11:09           ` Andreas Schwab
2003-02-05 21:56     ` Linus Torvalds
2003-02-07 14:56 ` Pavel Machek
2003-02-08 18:28   ` Larry McVoy
2003-02-08 19:36     ` Martin J. Bligh
2003-02-09 10:57     ` Pavel Machek
2003-02-09 14:15       ` Andrea Arcangeli
2003-02-13  1:50     ` Jamie Lokier
2003-02-13  1:57       ` Jamie Lokier

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='b1s23k$3je$1@penguin.transmeta.com' \
    --to=torvalds@transmeta.com \
    --cc=linux-kernel@vger.kernel.org \
    /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