Re: 2.5 changeset 1.952.4.2 corrupt in fs/jfs/inode.c

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Feb 05, 2003 at 12:09:03PM -0800, Andrew Morton wrote:
> Andrea Arcangeli <andrea@suse.de> wrote:
> >
> > it might be simply an error in the tarball, maybe Linus's tree isn't in
> > full sync with bk head. But something definitely is corrupt between
> > tarball and bk.
> 
> Well, the 2.5.59 BK tree shows that function using block_truncate_page() as
> well.
> 
> The question is why did the Jan 9 changeset in the 2.5.55 timeframe not
> appear in the tree until post-2.5.59.  Maybe on Jan 9 Linus only part-merged
> it by some means (making the web interface claim it is there), and this week
> completed the merge and updated the checkin comment?

I don't know how it is supposed to work, but this sounds quite messy, if
this is the case, how can you order the changesets?

I mean if that's "normal", then the changeset diffs that are on the ftp
site aren't something "constant" they can change over time when non
controversial stuff changes under them, and in turn it's pointless to
store them on kernel.org since they may be just changed in the bitkeeper
database by the time you go read them...

The way it should work to be cleaner, is that if Linus merged a
modification, no matter how, this modification gets *always* a new
changeset number at the head. Merging modifications in the past
invalidates every single changeset on kernel.org and in the mailing list
from that point in the past to the bk-head.

Andrea