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

Andrea Arcangeli
2003-02-05T20:15:18Z

On Wed, Feb 05, 2003 at 02:11:04PM -0600, Matt Reppert wrote:
> (CC'ing Linus because I have a question for him in here ... )
> On Wed, 5 Feb 2003 11:43:53 -0800
> Andrew Morton <akpm@digeo.com> wrote:
> >
> > http://linux.bkbits.net:8080/linux-2.5/cset@1.879.43.1?nav=index.html|ChangeSet@-8w
> >
> > And revtool shows that change on Jan 09 this year.
> >
> > But it does not appear in Linus's 2.5.59 tarball, and there appears to be no
> > record in bitkeeper of where this change fell out of the tree.
> >
> > In fact the above URL shows two instances of the same patch, with different
> > human-written summaries, on the same day.
> >
> > I believe that shaggy had some problem with the nobh stuff, so possibly the
> > January 9 change was reverted in some manner, and it was reapplied
> > post-2.5.59, and the web interface does now show the revert. Revtool does
> > not show it either. Nor the reapply.
> >
> > It is quite confusing. Yes, something might have gone wrong.
>
> I sit on the web interface a lot to see what's being merged. If you ask for
> it, it will give you a list of csets ordered by date, newest first. I've
> noticed sometimes that recently merged csets will appear to be older than
> the date they were merged, perhaps because they actually were that old in

if the date is old it's not a problem, I mean, it's ok if they're not
ordered by date of creation of the code. But it would make lots of sense
if the "past" could remain intact.

The problem is if a new changesets can appear in the past, rather than
being always added at the head (no matter the date). If they appear in
the past they can modify every single changeset diff from that point in
the past to the head.

Andrea