Given a particular file and a particular bitkeeper revision for the file, how can I tell
which version of the kernel incorporated that changeset?
In particular, I want to know about revision 1.65 of mm/rmap.c, which can be seen at
http://linux.bkbits.net:8080/linux-2.6/diffs/mm/[email protected]?nav=index.html|src/|src/mm|hist/mm/rmap.c
I want to know what the first version of Linux is to incorporate that change.
And please don't tell me to do a diff on all the 2.6 versions, because that's not efficient.
--
Timur Tabi
Staff Software Engineer
[email protected]
One thing a Southern boy will never say is,
"I don't think duct tape will fix it."
-- Ed Smylie, NASA engineer for Apollo 13
On Wed, 18 May 2005, Timur Tabi wrote:
> Given a particular file and a particular bitkeeper revision for the file, how
> can I tell which version of the kernel incorporated that changeset?
Someone else might answer that.
> In particular, I want to know about revision 1.65 of mm/rmap.c, which can be
> seen at
> http://linux.bkbits.net:8080/linux-2.6/diffs/mm/[email protected]?nav=index.html|src/|src/mm|hist/mm/rmap.c
>
> I want to know what the first version of Linux is to incorporate that change.
The first mainline version of Linux to incorporate it was 2.6.7-rc3
(SuSE, and the -mm tree, had it earlier).
Hugh
On Wed, 18 May 2005, Timur Tabi wrote:
> Hugh Dickins wrote:
>
> > The first mainline version of Linux to incorporate it was 2.6.7-rc3
> > (SuSE, and the -mm tree, had it earlier).
>
> How did you know that?
I know the patch because it went from Andrea to me to Andrew to Linus.
I have a copy of the 2.6.N trees here on my laptop so can quickly
verify my recollection that the first 2.6.N it appeared in was 2.6.7.
Then I searched through each ChangeLog-2.6.7-rcN at
http://ftp.kernel.org/pub/linux/kernel/v2.6/testing/
for comments on get_user_pages.
Hugh
Hugh Dickins wrote:
> The first mainline version of Linux to incorporate it was 2.6.7-rc3
> (SuSE, and the -mm tree, had it earlier).
How did you know that?
--
Timur Tabi
Staff Software Engineer
[email protected]
One thing a Southern boy will never say is,
"I don't think duct tape will fix it."
-- Ed Smylie, NASA engineer for Apollo 13
On Wed, May 18, 2005 at 09:11:32AM -0500, Timur Tabi wrote:
> Given a particular file and a particular bitkeeper revision for the file,
> how can I tell which version of the kernel incorporated that changeset?
>
> In particular, I want to know about revision 1.65 of mm/rmap.c, which can
> be seen at
> http://linux.bkbits.net:8080/linux-2.6/diffs/mm/[email protected]?nav=index.html|src/|src/mm|hist/mm/rmap.c
>
> I want to know what the first version of Linux is to incorporate that
> change.
>
> And please don't tell me to do a diff on all the 2.6 versions, because
> that's not efficient.
But that's how you have to do it, sorry. You have the patches, why
can't you just use grep? :)
Good luck,
greg k-h
Greg KH wrote:
> But that's how you have to do it, sorry. You have the patches, why
> can't you just use grep? :)
What does Linus do to keep track of these changes? Granted, he's not using BitKeeper any
more, but it does support release management, so I would presume he was tagging the
releases with it. What does he do now?
--
Timur Tabi
Staff Software Engineer
[email protected]
One thing a Southern boy will never say is,
"I don't think duct tape will fix it."
-- Ed Smylie, NASA engineer for Apollo 13
On Wed, 2005-05-18 at 10:11, Timur Tabi wrote:
> Given a particular file and a particular bitkeeper revision for the file, how can I tell
> which version of the kernel incorporated that changeset?
>
> In particular, I want to know about revision 1.65 of mm/rmap.c, which can be seen at
> http://linux.bkbits.net:8080/linux-2.6/diffs/mm/[email protected]?nav=index.html|src/|src/mm|hist/mm/rmap.c
>
> I want to know what the first version of Linux is to incorporate that change.
>
The most pragmatic thing to do is to take the comment from the
changeset, which in this case is "mm: get_user_pages vs. try_to_unmap"
and plop that into google as "changelog mm: get_user_pages vs.
try_to_unmap".. and that will point you very quickly to the right
release changelog that includes it, because the changelogs are generally
driven right from the comments.. in this case
http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.7-rc3
While this isn't scientific - it has a very high success rate and is
easy as pi..
On Wed, May 18, 2005 at 11:23:20AM -0500, Timur Tabi wrote:
> Greg KH wrote:
>
> >But that's how you have to do it, sorry. You have the patches, why
> >can't you just use grep? :)
>
> What does Linus do to keep track of these changes? Granted, he's not using
> BitKeeper any more, but it does support release management, so I would
> presume he was tagging the releases with it.
Yes, and that tagging worked just fine. You can see this too if you
want to check out a tree based on a tag.
> What does he do now?
Uses git, which will have the same issues as you are facing :)
Please remeber, with a distributed development system like this, going
off of the "date" means _nothing_. What matters is when that patch and
branch is merged into his tree, and to determine that, you will have to
dig around a bit.
And since you have raw patches, and know what you are looking for, the
solution should be very simple (hint, grep...)
Good luck,
greg k-h
On Wed, 18 May 2005, Greg KH wrote:
> > What does he do now?
>
> Uses git, which will have the same issues as you are facing :)
Both git and BK can do this.
Once you know which commit you want to check, the way to find out what the
first release was that contained that commit is perfectly straightforward:
you take each release, and see if the commit is reachable from that
release. You don't need to actually look at the patches, it's enough to
look at the revision tree.
In Git, you can basically do something like
for i in $releases
do
j=$(git-merge-base $commit $i)
if [ "$j" == "$commit" ]; then
echo $commit was in $i
fi
done
where "releases" is the list of SHA1 names for the commits of the releases
you're interested in, and "commit" is the SHA1 name of the commit you're
looking at.
In BK, you can do similar things with "bk cset" (and there's some other
helper things for it too), but I don't have the docs available any more,
so..
In all fairness, usually it _is_ easier to just do a grep for it if you
already have the release patches available. It's what I usually did
myself.
Linus