Hello Larry,
If you apply all changeset in order starting from 2.5.59 until 1.952.4.2
you should get a fs/jfs/inode.c like this:
void jfs_truncate(struct inode *ip)
{
jFYI(1, ("jfs_truncate: size = 0x%lx\n", (ulong) ip->i_size));
block_truncate_page(ip->i_mapping, ip->i_size, jfs_get_block);
^^^^^^^^^^^^^^^^^^^
but the changeset 1.952.4.2 is the below one and it shows:
@@ -378,7 +377,7 @@
void jfs_truncate(struct inode *ip)
{
- jFYI(1, ("jfs_truncate: size = 0x%lx\n", (ulong) ip->i_size));
+ jfs_info("jfs_truncate: size = 0x%lx", (ulong) ip->i_size);
nobh_truncate_page(ip->i_mapping, ip->i_size);
^^^^^^^^^^^^^^^^^^
so it thinks the function is called nobh_truncate_page and not
block_truncate_page.
Note, I'm using my own GPL software to checkout from the bitkeeper
servers (I don't want to miss the additional information stored in
proprietary form inside the bitkepper database and so I'm extracting it
all and storing it in a open manner locally, in a complete structured
form, they're live classes dumped to disk, not like the monolithic
patches in the cset/ directory where it's not trivial to manage all the
metadata to see all the evolution of a certain file or subsystem by
writing a few more lines of code that loads and use those classes) so it
could be my bug and not a bug in bitkeeper, no idea if it's reproducible
with bitkeeper. I hope I'm not wasting your time and that it's not a
bug from my part ;)
btw, the changeset would apply anyways despite the corrupted patch, if
I'd use the default fuzz level of patch, but still it looks corrupted
and a bug that needs fixing (either from my part or your part) so I'm
not going to ignore it even if it doesn't literally reject.
See:
http://linux.bkbits.net:8080/linux-2.5/[email protected]?nav=index.html|ChangeSet@-4w|[email protected]
I'd appreciate if you could check why bitkeeper thinks such function is
nobh_truncate_page and not block_truncate_page as my GPL software
pretends while it checkouts all the changesets from the bitkeeper
servers.
Thanks,
Andrea
Andrea Arcangeli <[email protected]> wrote:
>
> void jfs_truncate(struct inode *ip)
> {
> - jFYI(1, ("jfs_truncate: size = 0x%lx\n", (ulong) ip->i_size));
> + jfs_info("jfs_truncate: size = 0x%lx", (ulong) ip->i_size);
>
> nobh_truncate_page(ip->i_mapping, ip->i_size);
> ^^^^^^^^^^^^^^^^^^
This is the correct version. Since 2.5.59, jfs was switched over to not use
buffer_heads.
On Wed, Feb 05, 2003 at 10:23:08AM -0800, Andrew Morton wrote:
> Andrea Arcangeli <[email protected]> wrote:
> >
> > void jfs_truncate(struct inode *ip)
> > {
> > - jFYI(1, ("jfs_truncate: size = 0x%lx\n", (ulong) ip->i_size));
> > + jfs_info("jfs_truncate: size = 0x%lx", (ulong) ip->i_size);
> >
> > nobh_truncate_page(ip->i_mapping, ip->i_size);
> > ^^^^^^^^^^^^^^^^^^
>
> This is the correct version. Since 2.5.59, jfs was switched over to not use
> buffer_heads.
In this context I don't mind which is the correct one.
I only would like to know what is supposed to be stored inside the
2.5.59 tarball on kernel.org and what is supposed to be changed between
2.5.59 and the 1.952.4.2 changeset.
The one I see in 2.5.59 (I double checked the tar.gz) is this:
void jfs_truncate(struct inode *ip)
{
jFYI(1, ("jfs_truncate: size = 0x%lx\n", (ulong) ip->i_size));
block_truncate_page(ip->i_mapping, ip->i_size, jfs_get_block);
And I see no changes in this area starting from 2.5.59, until changeset
1.952.4.2. So I deduce my software is right and that either the 2.5.59
tarball or the 1.952.4.2 changeset are corrupt.
I can't yet fetch a full tree out of bitkepper yet (you know the network
protocol must be reverse engeneered first), I can only fetch
incrementals with metadata and raw patch so far because this is the
thing I care about most, after I've all the changesets in live form in
my db I don't mind too much about the ability to checkout a the whole
tree too, since I can do the same starting from my open db rather than
using the proprietary one.
Andrea
Andrea Arcangeli <[email protected]> wrote:
>
> In this context I don't mind which is the correct one.
>
> I only would like to know what is supposed to be stored inside the
> 2.5.59 tarball on kernel.org and what is supposed to be changed between
> 2.5.59 and the 1.952.4.2 changeset.
>
> The one I see in 2.5.59 (I double checked the tar.gz) is this:
>
> void jfs_truncate(struct inode *ip)
> {
> jFYI(1, ("jfs_truncate: size = 0x%lx\n", (ulong) ip->i_size));
>
> block_truncate_page(ip->i_mapping, ip->i_size, jfs_get_block);
>
> And I see no changes in this area starting from 2.5.59, until changeset
> 1.952.4.2. So I deduce my software is right and that either the 2.5.59
> tarball or the 1.952.4.2 changeset are corrupt.
OK. I see.
No, I cannot explain this either. Shortly after 2.5.55, this change appears in the
web interface:
http://linux.bkbits.net:8080/linux-2.5/[email protected]?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.
Hi Andrea
It was in cset 1.879.43.1 that the change was made.
Long time before the cset you noted.
To me it looks like the same change were applied twice to Linus's
BK tree.
[cset's from a vanilla clone of Linus'es BK tree].
Sam
On Wed, Feb 05, 2003 at 07:45:35PM +0100, Andrea Arcangeli wrote:
> I can't yet fetch a full tree out of bitkepper yet (you know the network
> protocol must be reverse engeneered first), I can only fetch
> incrementals with metadata and raw patch so far because this is the
> thing I care about most, after I've all the changesets in live form in
> my db I don't mind too much about the ability to checkout a the whole
> tree too, since I can do the same starting from my open db rather than
> using the proprietary one.
Why not save effort, and just grab from http://ftp.kernel.org/pub/linux/kernel/v2.5/testing/cset/
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Wed, Feb 05, 2003 at 11:43:53AM -0800, Andrew Morton wrote:
> Andrea Arcangeli <[email protected]> wrote:
> >
> > In this context I don't mind which is the correct one.
> >
> > I only would like to know what is supposed to be stored inside the
> > 2.5.59 tarball on kernel.org and what is supposed to be changed between
> > 2.5.59 and the 1.952.4.2 changeset.
> >
> > The one I see in 2.5.59 (I double checked the tar.gz) is this:
> >
> > void jfs_truncate(struct inode *ip)
> > {
> > jFYI(1, ("jfs_truncate: size = 0x%lx\n", (ulong) ip->i_size));
> >
> > block_truncate_page(ip->i_mapping, ip->i_size, jfs_get_block);
> >
> > And I see no changes in this area starting from 2.5.59, until changeset
> > 1.952.4.2. So I deduce my software is right and that either the 2.5.59
> > tarball or the 1.952.4.2 changeset are corrupt.
>
> OK. I see.
>
> No, I cannot explain this either. Shortly after 2.5.55, this change appears in the
> web interface:
>
>
> http://linux.bkbits.net:8080/linux-2.5/[email protected]?nav=index.html|ChangeSet@-8w
yes I found it too a few minutes ago.
>
> 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.
yes, this is exactly the problem I run into.
>
> 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.
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.
Andrea
On Wed, Feb 05, 2003 at 07:42:57PM +0000, Dave Jones wrote:
> On Wed, Feb 05, 2003 at 07:45:35PM +0100, Andrea Arcangeli wrote:
>
> > I can't yet fetch a full tree out of bitkepper yet (you know the network
> > protocol must be reverse engeneered first), I can only fetch
> > incrementals with metadata and raw patch so far because this is the
> > thing I care about most, after I've all the changesets in live form in
> > my db I don't mind too much about the ability to checkout a the whole
> > tree too, since I can do the same starting from my open db rather than
> > using the proprietary one.
>
> Why not save effort, and just grab from http://ftp.kernel.org/pub/linux/kernel/v2.5/testing/cset/
I used them so far, but they're as useless as the patches mailing list
for my purposes, first they're not useful to checkout a tree, the order of
the changesets I mean, and they don't tell when a certain kernel revision
matches a changeset, I'm checking out Linus's tree with it, they don't
provide live metadata easy to browse in software, to monitor in
background automatically, I need to see all the evolution of a certain
file or subsystem with all the metadata and raw patches with a few lines
of python, and last but not the least I like it to run in real time w/o
delays.
In short I'm extracting the whole database and I'm storing it in an open
form so I can manipulate it as I need. I don't watch branches, I only
fetch the main branch.
This makes very trivial also to checkin the whole thing into another
version control system and to keep it uptodate in background even if
this isn't my purpose.
I don't think it's worthwhile to do more than that on the bk side, I
mean, it's not an openbitkepper thing, I would rather write something
from scratch rather than reverse engeneering the whole thing just to
provide compatibility, once you've all the info in open form, you can
use it as a transient format that allows you to fill it into any other
project.
What matters to me is only the info and the easiest way to manipulate it
in software, it's much more powerful than what bitkeeper can do this way
because I program it, downside is that I need some more disk space ;).
Andrea
On Wednesday 05 February 2003 11:40, Andrea Arcangeli wrote:
> I'd appreciate if you could check why bitkeeper thinks such function
> is nobh_truncate_page and not block_truncate_page as my GPL software
> pretends while it checkouts all the changesets from the bitkeeper
> servers.
Andrea,
The change from block_truncate_page to nobh_truncate_page was done in
Changeset 1.879.43.1. This was created on January 9th, but not merged
into Linus' tree until Monday, so it is not in 2.5.59. I think the
date of the changeset preceding 2.5.59 is causing the confusion.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
(CC'ing Linus because I have a question for him in here ... )
On Wed, 5 Feb 2003 11:43:53 -0800
Andrew Morton <[email protected]> wrote:
>
> http://linux.bkbits.net:8080/linux-2.5/[email protected]?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
On Wednesday 05 February 2003 14:10, Andrea Arcangeli wrote:
> On Wed, Feb 05, 2003 at 02:04:21PM -0600, Dave Kleikamp wrote:
> > The change from block_truncate_page to nobh_truncate_page was done
> > in Changeset 1.879.43.1. This was created on January 9th, but not
> > merged into Linus' tree until Monday, so it is not in 2.5.59. I
> > think the
>
> if you think it's normal the thing sounds very messy. I mean, how can
> a changeset be numbered 1.879.43.1 and not be included in 2.5.59?
>
> The way I understood it is that when Linus merges "stuff", this
> "stuff" gets a changeset number in the future, not in the past. No
> matter if the "stuff" was created in the past. Is this the case or
> not?
I don't understand the changeset numbering myself, so I guess Larry will
have to answer this one.
> I mean, somehow there must be a way to number the changesets so that
> applying them in order generates something coherent.
>
> Andrea
--
David Kleikamp
IBM Linux Technology Center
On Wed, Feb 05, 2003 at 02:04:21PM -0600, Dave Kleikamp wrote:
> On Wednesday 05 February 2003 11:40, Andrea Arcangeli wrote:
> > I'd appreciate if you could check why bitkeeper thinks such function
> > is nobh_truncate_page and not block_truncate_page as my GPL software
> > pretends while it checkouts all the changesets from the bitkeeper
> > servers.
>
> Andrea,
> The change from block_truncate_page to nobh_truncate_page was done in
> Changeset 1.879.43.1. This was created on January 9th, but not merged
> into Linus' tree until Monday, so it is not in 2.5.59. I think the
if you think it's normal the thing sounds very messy. I mean, how can
a changeset be numbered 1.879.43.1 and not be included in 2.5.59?
The way I understood it is that when Linus merges "stuff", this "stuff"
gets a changeset number in the future, not in the past. No matter if the
"stuff" was created in the past. Is this the case or not?
I mean, somehow there must be a way to number the changesets so that
applying them in order generates something coherent.
Andrea
Andrea Arcangeli <[email protected]> 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?
On Wed, Feb 05, 2003 at 12:09:03PM -0800, Andrew Morton wrote:
> Andrea Arcangeli <[email protected]> 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
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 <[email protected]> wrote:
> >
> > http://linux.bkbits.net:8080/linux-2.5/[email protected]?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
On Wed, 5 Feb 2003, 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 <[email protected]> wrote:
> >
> > http://linux.bkbits.net:8080/linux-2.5/[email protected]?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.
There is a record in BK, you just have to find the merge.
> > In fact the above URL shows two instances of the same patch, with different
> > human-written summaries, on the same day.
Which if true would easily happen if the patches was independently
committed to two trees and then those trees were later merged.
However, in this case I don't think there is any real duplication, and
what you're looking at is the "all diffs" part (whole changeset) and the
"per-file diffs" part. And the changeset comment is slightly different for
the per-file comment. (Look at some more extensive changeset that modifies
multiple files to see this more clearly).
The way it then came into my tree is through:
[email protected], 2003-02-03 14:58:24-08:00, [email protected]
Merge http://jfs.bkbits.net/linux-2.5
into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux
(you can use "bk changes -e" to also get merge changes, or you can try to
follow the merges in the graphical tree shown by "bk revtool").
So it was merged into _my_ tree yesterday, but it's been in shaggy's tree
since Jan 9th.
> 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.
Absolutely. There are two totally independent events: the event of
committing a patch to a tree (which was done by shaggy some time ago) and
the event of merging the trees into my tree (which was done by me
yesterday).
Use "bk revtool" to get a mental picture of this. I don't find "bk
revtool" that useful for some other reasons (bad cut-and-paste behaviour,
sometimes horribly hard to find things), but it's a good way to mentally
visualize the "topology" of the changes.
("bk revtool" probably works a lot better on simpler projects, with the
kernel it just gets too complicated too fast to be horribly useful).
Linus
Andrea Arcangeli wrote:
>
> On Wed, Feb 05, 2003 at 12:09:03PM -0800, Andrew Morton wrote:
> > Andrea Arcangeli <[email protected]> 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?
>
Dave says that the Jan 9 date was when he committed it locally. It
was pushed to Linus this week, and the tracking shows Dave's date,
not Linus's.
I didn't know Dave was using bitkeeper. Sorry noise.
On Wed, Feb 05, 2003 at 09:10:55PM +0100, Andrea Arcangeli wrote:
> > Andrea,
> > The change from block_truncate_page to nobh_truncate_page was done in
> > Changeset 1.879.43.1. This was created on January 9th, but not merged
> > into Linus' tree until Monday, so it is not in 2.5.59. I think the
>
> if you think it's normal the thing sounds very messy. I mean, how can
> a changeset be numbered 1.879.43.1 and not be included in 2.5.59?
cset 1.952.1.4 is the one that Linus released 2.5.59 on.
Now I started doing some development based on cset 1.875 - a few days older.
Tomorrow Linus release a new kernel, cset 1.973 for example.
Next week Linus merge my work, that will be numbered 1.875.1.1..1.875.1.3
You will see that my cset will be listed on the web on the date where
I did the commit, but it will not appear on kernel.org until
Linus merge my stuff.
So you cannot deduct from the numbers in what release a certain cset belongs.
The fact that cset's appear on the web as they are orginally committed
is annoying tracking the kernel, and Larry sometime ago noted that they
may do some changes in that respect.
Sam
On Wed, Feb 05, 2003 at 09:34:45PM +0100, Sam Ravnborg wrote:
> The fact that cset's appear on the web as they are orginally committed
> is annoying tracking the kernel, and Larry sometime ago noted that they
> may do some changes in that respect.
I don't mind too much where they appear. I assumed they would appear at
the head if they are merged last, but it's not important.
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'm lost...
Also note that the fact changesets can be merged in the past, and not
alwayas in the head, means that all the cset/ directory can be
completely corrupt and useless, because if regenerated at any given time
it would produce different diffs, unless this order that I'm searching
for isn't preseved internally by bk. In short the cset directory sounds
like a joke unless bk internally keeps the ordering, and in such case I
should find a way to get that information out of bk too, that's the last
bit I need to checkout coherent.
Andrea
On Wed, 5 Feb 2003, Andrea Arcangeli wrote:
>
> 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 past does remain intact, but the thing is, the revision history isn't
a simple time-ordered thing. In fact, it clearly cannot be, since that
would be fundamentally impossible in any disconnected distributed system.
So the revision history is really a two-dimensional merge-tree rather than
a linear list, and any historical point is really specified by the _key_
of the top-of-branch ChangeSet, not by some time or a revision number
(revision numbers are, like time, obviously not unique in a disconnected
distributed system, so they can clearly not be anything but temporary
indexes).
So if you take my current tree, the checkin by shaggy is called
'1.952.4.2', but that is not it's real name, since that will quite
possibly change the next time I merge with somebody else (since they
used a different numbering). The key for that change is
[email protected]|ChangeSet|20030117201730|50555
which is universally unique in the tree, and will be stable across merges.
So if you want to get to the point where shaggy was when he made that
change, right now you can do
bk clone -r1.952.4.2 linus-tree shaggys-old-tree
but that won't work in the general case. You can always see what a key
(or list of keys) corresponds to with something like
echo xxxxxxxx | bk changes -
where xxxx is the unchanging key (this will also show you what the
revision is called in that tree).
Or, if you want to see what my tree looked like before I merged shaggy's
tree, you find the merge-point (currently 1.974), and decide which of the
"befores" you care about ("my" before is 1.973 in my current tree, while
the other side before is now called 1.969.1.2).
But with lots of merges and new patches, you can easily drown in the
information.
> 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.
I think you will really understand the BK layout if you understand what my
"changelog generator" does (part of my BK/tools repository). The thing to
understand is that the difference between two points in the tree is NOT a
"linear walk" between those two revisions (because no such linear order
exists), but a difference between the _sets_ of changesets in the two
trees.
So what "changelog" will do is:
bk set -n -d -r"$FROM" -r"$TO" |
bk -R prs -h -d'$unless(:MERGE:){<:P:@:HOST:>\n$each(:C:){\t(:C:)\n}\n}' -
where the "bk set" part will do the "set operation" (think algebra here)
of the difference (-d) between the trees specified with FROM/TO. The "-n"
thing will then send that list of changesets to <stdout>, and then the "bk
prs" will print out the information about those changesets in a readable
format.
Do you usually care? No. I don't ever actually do the above operation by
hand, it's mainly just a scripting feature. It looks complicated, and yes
to some degree it is, because you have to think about points that don't
lie on the "straight line" between two revisions.
Linus
In article <[email protected]>,
Andrea Arcangeli <[email protected]> wrote:
>
>if you think it's normal the thing sounds very messy. I mean, how can
>a changeset be numbered 1.879.43.1 and not be included in 2.5.59?
You're thinking all wrong.
If you're trying to import BK into a traditional (CVS-like) setup, you
are bound to fail. In fact, it sounds like that is exactly what you're
trying to do, and it looks like you simply don't understand
distribution.
Don't feel bad, none of the CVS/Subversion people seem to get it either.
A revision number clearly _cannot_ be a ID in a distributed environment.
What happens when two people both create 1.1 and try to merge? Something
has to give, and the thing that has to give is the notion that revision
numbers "mean" anything.
Yes, revision numbers do show the tree structure of the SCM, but since
merging (by definition) changes the tree structure, then clearly by
definition the revision numbers have to change on a merge when that
happens.
Revision numbers do not change if:
- you only work in one tree (ie use BK as a plain CVS replacement)
- you only ever merge changes to the top-of-tree (ie no branches)
but immediately when two people have worked on two trees in parallel
without synchronizing at each step (ie true distributed development),
revision numbers _have_ to be fixed up when a merge happens.
So your question is meaningless: "how can a changeset be numbered
1.879.43.1 and not be included in 2.5.59" is simply not a valid question
in a distributed environment.
My current BK tree obviously contains 2.5.59 as a proper subtree. That,
however, does NOT mean that the revision numbers would be a proper
subset.
Think of it this way in a simplified revision tree:
rev 1.1 <- initial release (call it v2.5.0)
rev 1.2 <- I made a change, and released it as v2.5.1
Ok. Before I had released v2.5.1, somebody else (say, shaggy), had taken
my 2.5.0 tree, and made his own changes to it. So now _he_ has a tree
that looks like
rev 1.1 <- initial release (v2.5.0)
rev 1.2 <- shaggy's private change, based on 2.5.0
So now we decide to merge. Two things can happen: shaggy can merge my
changes, and I can merge his. Let's say shaggy decides to merge my
changes into his tree: that will be his "1.3" point, but the my old 1.2
rev obviously will end up being just a branch to him, and will be a
branch based on our largest common denominator, ie 1.1.
So to shaggy, after the merge, we will have
rev 1.1 <- initial release (v2.5.0)
rev 1.2 <- shaggy's private change
rev 1.1.1 <- my change, tagged as v2.5.1, is just a branch to shaggy
rev 1.3 <- merge point
Note how rev 1.2 in my original v2.5.1 tree is now called 1.1.1, and
what is now 1.2 doesn't even _exist_ in my tagged v2.5.1.
>The way I understood it is that when Linus merges "stuff", this "stuff"
>gets a changeset number in the future, not in the past. No matter if the
>"stuff" was created in the past. Is this the case or not?
No. There _is_ no "future" or "past". Read up on any distributed
system, and realize that relative time can only be determined by how
fast the interconnect is, and if you have disconnected systems (which is
the whole _point_ of doing distributed SCM), then no such thing can
exist.
In other words, time does not exist between two distributed SCM trees.
The thing that "gels" the time is the act of merging, and only at that
point do we get a _partial_ ordering of changesets.
It's kind of like the cone of light in relativistic physics, except the
speed of light between two points is arbitrary and depends entirely on
when people decided to merge. Like in relativistic physics, a totally
ordered "before" and "after" only exist within one frame of reference:
immediately when you look at multiple frames of reference, you get only a
partial ordering, and no equality of time.
Linus
In article <[email protected]>,
Andrea Arcangeli <[email protected]> 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
> (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 ... )
Yes, NSS in glibc is the world's worst garbage. Glibc segfaults if there
is no /etc/nsswitch.conf. Nice.
We can go buy another machine for glibc2.3, I just need to know what redhat
release uses that. If there isn't one, what distro uses that?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> 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.
That is an incorrect statement. You are comparing a moving target with
a snapshot. If you roll the moving target back to the snapshot point
you get the tarball contents.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Wed, Feb 05, 2003 at 03:31:15PM -0800, Larry McVoy wrote:
> We can go buy another machine for glibc2.3, I just need to know what redhat
> release uses that. If there isn't one, what distro uses that?
redhat 8.0 uses a prerelease of glibc2.3, the current redhat beta uses
glibc 2.3.1+CVS, dito for debian unstable.
On Wed, 2003-02-05 at 23:31, Larry McVoy wrote:
> > (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 ... )
>
> Yes, NSS in glibc is the world's worst garbage. Glibc segfaults if there
> is no /etc/nsswitch.conf. Nice.
bugzilla is your friend
On Thu, Feb 06, 2003 at 12:45:55AM +0000, Alan Cox wrote:
> On Wed, 2003-02-05 at 23:31, Larry McVoy wrote:
> > > (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 ... )
> >
> > Yes, NSS in glibc is the world's worst garbage. Glibc segfaults if there
> > is no /etc/nsswitch.conf. Nice.
>
> bugzilla is your friend
Excuse my ignorance but how is that going to help me? I know the problem
and the work around so is there some magic voodoo chant in a bugzilla db
someplace which will make glibc not segfault without changing the system?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Wed, Feb 05, 2003 at 11:37:05PM +0000, Christoph Hellwig wrote:
> On Wed, Feb 05, 2003 at 03:31:15PM -0800, Larry McVoy wrote:
> > We can go buy another machine for glibc2.3, I just need to know what redhat
> > release uses that. If there isn't one, what distro uses that?
>
> redhat 8.0 uses a prerelease of glibc2.3, the current redhat beta uses
> glibc 2.3.1+CVS, dito for debian unstable.
And is everyone happy with 8.0's glibc, if we offer that up until 8.1 comes
out? If so, we'll buy a machine and add it to the build cluster this week.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> On Thu, Feb 06, 2003 at 12:45:55AM +0000, Alan Cox wrote:
> > On Wed, 2003-02-05 at 23:31, Larry McVoy wrote:
> > > > (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 ... )
> > >
> > > Yes, NSS in glibc is the world's worst garbage. Glibc segfaults if there
> > > is no /etc/nsswitch.conf. Nice.
> >
> > bugzilla is your friend
>
> Excuse my ignorance but how is that going to help me? I know the problem
> and the work around so is there some magic voodoo chant in a bugzilla db
> someplace which will make glibc not segfault without changing the system?
Yes! Say it with me:
"I will let someone know so they can fix it. Shazam!"
:))
M
> "I will let someone know so they can fix it. Shazam!"
Hmm, while I think that glibc should be fixed my general response is that
you shouldn't be running a statically linked version, which is probably
the cause of the guy's problems. Both our experience and lots of user
experience is that if you run the glibc2.2 version on a glibc2.3 system
it works fine.
The only reason we made a statically linked version available was for
Richard Gooch who insisted on maintaining his own a.out based distro.
I haven't heard from him in months so I'll nuke that image and maybe
the problem is gone.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Wed, 2003-02-05 at 18:57, Larry McVoy wrote:
> And is everyone happy with 8.0's glibc, if we offer that up until 8.1 comes
> out? If so, we'll buy a machine and add it to the build cluster this week.
I have had no problem with RH 8.0's glibc 2.2.90 release, which is a
countable number of patches away from 2.3 release anyhow. It is also
API and ABI compatible. In short, its fine.
I have recently moved my workstation to glibc 2.3 as from 8.1 beta, and
it too is good.
Only complaint is sched_{set|get}affinity is prototyped wrong... grr.
And, yes, I reported it and sent a patch to libc-alpha.
Robert Love
On 2/5/2003 11:31 PM, Larry McVoy wrote:
>>(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 ... )
>
>
> Yes, NSS in glibc is the world's worst garbage. Glibc segfaults if there
> is no /etc/nsswitch.conf. Nice.
>
> We can go buy another machine for glibc2.3, I just need to know what
redhat
> release uses that. If there isn't one, what distro uses that?
Matt,
I _think_ the RedHat glibc2.3 has the NSS patch to avoid this problem.
If you're into rolling your own you can find some info here:
http://www.linuxfromscratch.org/view/cvs/chapter06/glibc.html
I wanted to to run the newest version of glibc on my LFS machine, and
had to start from scratch (again) because of this.
On Wed, Feb 05, 2003 at 03:31:15PM -0800, Larry McVoy wrote:
> We can go buy another machine for glibc2.3
Buy a machine? Why not use UML?
http://user-mode-linux.sourceforge.net/
umlbuilder can build Redhat 8.0 images (along with loads of others)
http://umlbuilder.sourceforge.net/
http://umlbuilder.sourceforge.net/distributions.shtml
There are debian root filing systems on the UML site.
Alternatively use the image created by umlbuilder and chroot into it.
Mount --bind your source directory and away you go...
--
Nick Craig-Wood
[email protected]
Hi,
On Wed, 5 Feb 2003, Linus Torvalds wrote:
> 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.
If I understand this correctly, it's possible, but just really painful,
because you have to work with lots of branches and do a lot manually.
You can create branches "in the past" without problems, you just can't
insert a patch between two revisions.
(DISCLAIMER: the following might be absolute garbage, as all this is
only derived from second hand sources. I have no license to run bk, so I
can't verify this information.)
So in CVS terms cloning a tree would mean to get a read only version of
your repository and locally I can only a create branch:
cvs tag -D now branch1-point
cvs tag -b -r branch1-point branch1
cvs up -r branch1
and now I can work on that branch. If I want to merge now with you, I had
first had to get all the new changes, which would be applied to the head.
After this I had to create a new branch:
cvs tag -D now branch2-point
cvs tag -b -r branch2-point branch2
Now I can merge my changes into the new branch:
cvs up -j branch1-point -j branch1 -r branch2
(fix conflicts)
cvs commit
If you wanted to merge my changes, it would be enough to merge the last
branch:
cvs up -j branch2-point -j branch2
(fix conflicts)
cvs commit
Past branches had only to be recreated to also get the history
information.
AFAICT bk now handles all this transparently and mangles it to into a
single repository. The price is that you can have only a single branch
per repository and for every new development (branch) you have to clone a
new repository.
bye, Roman
[email protected] (Linus Torvalds) writes:
|> 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.
I think with "cvs tag -b -r whatever" you can create a branch on any
point of the CVS history.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 N?rnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Feb 05, 2003 15:57 -0800, Larry McVoy wrote:
> On Wed, Feb 05, 2003 at 11:37:05PM +0000, Christoph Hellwig wrote:
> > On Wed, Feb 05, 2003 at 03:31:15PM -0800, Larry McVoy wrote:
> > > We can go buy another machine for glibc2.3, I just need to know what
> > > redhat release uses that. If there isn't one, what distro uses that?
> >
> > redhat 8.0 uses a prerelease of glibc2.3, the current redhat beta uses
> > glibc 2.3.1+CVS, dito for debian unstable.
>
> And is everyone happy with 8.0's glibc, if we offer that up until 8.1 comes
> out? If so, we'll buy a machine and add it to the build cluster this week.
UML is your friend here - you can have a whole set of distros/revisions all
on the same host.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
> > And is everyone happy with 8.0's glibc, if we offer that up until 8.1 comes
> > out? If so, we'll buy a machine and add it to the build cluster this week.
>
> UML is your friend here - you can have a whole set of distros/revisions all
> on the same host.
We do our builds in parallel on all platforms (except s390, that one
is special for obvious reasons). Even with a fast machine it takes a
while to do the build/test cycle. So we allocate a machine/platform.
The cost of the machine doesn't bother me that much, actually, it's
the power. The power bill for our build cluster is about $800/month.
I've thought of putting all the machines on a software controlled
power switch and turning them on when we need it but bring up on some
of these is manual (headless machines that don't want to be headless,
the alpha machine refuses to autoboot, etc) and my experience is that
power cycling is a great way to make machines die young.
So we're sort of stuck with the current model. It's not that bad, we
use cheap machines, it will cost me maybe $400 to put a new machine
up, that's hardly something to get excited about if it makes some
problems go away.
What I'd really like to know is if we really need a glibc2.3 image.
Would the guy who had the segfaults step foward and confirm/deny the
use of the static image? We haven't had any other problem reports
related to glibc2.3 so it may be there is no need to do anything but
kill the static version. I can always hand roll one for Gooch. Does
anyone else need a.out support?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Thu, 6 Feb 2003 09:30:50 -0800
Larry McVoy <[email protected]> wrote:
> What I'd really like to know is if we really need a glibc2.3 image.
> Would the guy who had the segfaults step foward and confirm/deny the
> use of the static image? We haven't had any other problem reports
> related to glibc2.3 so it may be there is no need to do anything but
> kill the static version.
Indeed; I've had time to try the glibc2.2 version, and this seems to
work fine running a quick bk changes. The static version is what was
segfaulting. Sorry for the noise.
Thanks,
Matt
So statically linking against glibc-2.2 crashes under glibc-2.3(-aware-kernel)?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On Fri, Feb 07, 2003 at 05:18:10PM +0100, Horst von Brand wrote:
> So statically linking against glibc-2.2 crashes under glibc-2.3(-aware-kernel)?
Statically linking glibc 2.2.4 into BK will cause it to crash on some systems.
In general, we offer up the static image for people who aren't running glibc
based systems.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Hi!
> Note, I'm using my own GPL software to checkout from the bitkeeper
> servers (I don't want to miss the additional information stored in
Are you going to put up copy of that sw somewhere? I guess more people
are interested...
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
> > Note, I'm using my own GPL software to checkout from the bitkeeper
> > servers (I don't want to miss the additional information stored in
>
> Are you going to put up copy of that sw somewhere? I guess more people
> are interested...
Two things:
1) We're going to make a CVS archive of Linus tree available, automatically
updated, and we'll rsync it to some public place like kernel.org so you
can get at the data in a way you want with no BK involved at all.
2) If you beat on our servers with that stupid script, we'll shut down the
http access. Give us a break already.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> Two things:
>
> 1) We're going to make a CVS archive of Linus tree available,
> automatically updated, and we'll rsync it to some public place like
> kernel.org so you can get at the data in a way you want with no BK
> involved at all.
Great news - thanks very much for doing this.
It should quell people's fears.
M.
Hi!
> > > Note, I'm using my own GPL software to checkout from the bitkeeper
> > > servers (I don't want to miss the additional information stored in
> >
> > Are you going to put up copy of that sw somewhere? I guess more people
> > are interested...
>
> Two things:
>
> 1) We're going to make a CVS archive of Linus tree available, automatically
> updated, and we'll rsync it to some public place like kernel.org so you
> can get at the data in a way you want with no BK involved at all.
I like that.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
On Sun, Feb 09, 2003 at 11:57:52AM +0100, Pavel Machek wrote:
> Hi!
>
> > > > Note, I'm using my own GPL software to checkout from the bitkeeper
> > > > servers (I don't want to miss the additional information stored in
> > >
> > > Are you going to put up copy of that sw somewhere? I guess more people
> > > are interested...
> >
> > Two things:
> >
> > 1) We're going to make a CVS archive of Linus tree available, automatically
> > updated, and we'll rsync it to some public place like kernel.org so you
> > can get at the data in a way you want with no BK involved at all.
>
> I like that.
Yes. This way the information will be stored in a open standard and
downloadable with an open protocol in real time. The backup of the CVS
repository to kernel.org maybe is enough once per month or less. It is
only meant to be 100% sure not to lose the whole critical info, losing
one month would be nothing compared to losing it all. And at the same
time Linus and others can keep using bitkeeper if they can agree with
its proprietary licence.
I'm sorry Larry has to do all the work to setup the CVS checkins by
himself, I wish I could help him, that would be more than fair, just let
me know if I can contribute in any way with the setup.
As for the format of the checkins I suggested Larry to tag the tree with
an unique ID (changeset number is ok if it's unique and it doesn't
change on the bk side, but we don't care too much about the tag name)
after every checkin of a changeset. The cvs tags will be equivalent to
the changesets in bitkeeper. For the metadata belonging to the checkin I
suggested filling the cvs log this way:
ChangeSet: xxxx
Date: xxx
Author: xxx
Files: [ 'fs/inode.c', 'fs/dquote.c' ]
xxxxxComments herexxxx
xxxxxxxxxx
xxxxxxxxx
xxxx
(unsure if the changeset line is really needed, also unsure about the
files line when files are deleted)
So it will be trivial to extract the whole metadata, shall we need to
feed it in another database, or shall we need to automate searching
function on the information provided in CVS.
A simple `cvs log COPYING` will show all the changesets. A cvs rdiff
between two cvs tags will show the files involved and their revision
numbers, a cvs log will tell us the changeset metadata between these two
revision numbers that is effectively the metadata belonging to the whole
changesets. It's not the most handy format if your object is to extract
the data, but this way we won't need to reinvent the wheel for doing the
checkouts and diffs against Linus's tree that should be by far the
common usage, so it makes sense to me, especially because this format is
just designed to be efficient in doing the checkouts of the tree so it
will be safe to use for Larry's internet connection.
One detail is that the tree will be linearized (the last bit I needed to
make bkweb really useful), in the sense the old checkins in branched
bk trees, will showup as an unique changeset in the CVS, and it will
showup always as the head revision in CVS. I think it should be fine
since it will effectively match the way Linus merge stuff, i.e. a bk
pull will generate a single changeset in CVS.
The first priority is not to risk losing information on the evolution of
Linux, and this will be achieved this way, so I'm very happy! :)
Thanks.
Andrea
PS. if Larry don't want to risk paying an higher internet bill for the
future CVS users that right now obviously have to download from
kernel.org (and also because CVS is more network hungry than than bk I
believe), I'm sure various organizations (I could imagine osdl.org for
istance) could offer to host the kernel CVS tree too and Larry would
only need to pay the upload of the few kbytes of the checkins, without
paying for the plenty mbytes downloads. It obviously makes no difference
to the CVS users, this is definitely up to Larry.
On Thu, 2003-02-06 at 11:02, Nick Craig-Wood wrote:
> On Wed, Feb 05, 2003 at 03:31:15PM -0800, Larry McVoy wrote:
> > We can go buy another machine for glibc2.3
>
> Buy a machine? Why not use UML?
For something as simple as this you do not need anything more than
chroot so one box should do for all linux(glibc) versions.
But something more like vmware is needed if you also want to have window
and all the other X86 OS on the same box at the same time.
Larry McVoy wrote:
> 1) We're going to make a CVS archive of Linus tree available, automatically
> updated, and we'll rsync it to some public place like kernel.org so you
> can get at the data in a way you want with no BK involved at all.
Why not rsync the SCCS tree and let others worry about format
conversions? Presumably that would be much less work. (I'm
presuming, I know).
-- Jamie
I wrote:
> Why not rsync the SCCS tree and let others worry about format
> conversions? Presumably that would be much less work. (I'm
> presuming, I know).
Sorry if the tone of that seemed a bit harsh.
I mean that it might be less work for Larry to just mirror the SCCS tree
which Bitkeeper itself maintains - less overhead for Bitmover.
Just a suggestion.
cheers,
-- Jamie