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

[Matt Reppert <arashi@yomerashi.yi.org>]

(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
the parent repository. Is cset age preserved across repositories? It seems
to be.

If this is the case, then the cset was merged recently but the actual change
was done a long time ago. When did this get merged?

(BTW, Larry, the bk binaries segfault on my (glibc 2.3.1) i686 system. Any
chance we could see binaries linked against 2.3.x? There's NSS badness between
2.2 and 2.3 that causes even static binaries to segfault ... )

Thanks,
Matt