This page appears to contain material that is no longer relevant. Please help improve this page by updating its content.
This page is proposed for deletion. See our wiki cleanup plan for more information.
Fringe Kernel Work
I define "fringe" kernel work as that done by someone who is not a core developer, and who only communicates back to the community via patches. You are probably developing the latest and greatest kernel feature, and need to keep up with the official release while you do it, but be easily able to create your patch set at any time.
hg clone http://www.kernel.org/hg/linux-2.6/
This tree you will never touch directly; it is a copy of where Linus is at
hg clone linux-2.6 linux-2.6-working
Start doing your work on the linux-2.6-working tree; make commits as necessary, etc.
You will want to tag your first commit to make it easier to create diffs of your work. Use a local tag, because it is only for your reference within the local tree. So after your first commit do
hg tag kernel-import
or some similar tag. You can then get all your changes against the kernel you have downloaded from with
hg diff kernel-import:tip
It is now several days/weeks later, and you need to update your changes against the latest upstream versions.
Firstly, update the upstream tree
cd linux-2.6 hg pull
There shouldn't be any conflicts or issues, because you have not changed anything locally
Now create a new update tree, cloned from the latest upstream version (just as you did when you started)
hg clone linux-2.6 linux-2.6-update
Pull into the update tree your dev tree
cd linux-2.6-update hg pull ../linux-2.6-working
At this point your project has MultipleHeads -- one from your old working tree and one from the new tree you are merging into.
You will now need to merge the pulled changes into the new update tree. Do this with
hg update -m
Hopefully there won't be any conficts, but if there are you will have to resolve them.
Once done, the final step is to commit your changes into the new tree.
hg commit -m "merge to new linus tree"
Now create a tag again, so you can easily refer to just your changes later
hg tag kernel-import
Export your patches
Your changeset should now be on the the tip of the update tree. So the update tree becomes the new working tree, and you can archive the old working tree.
You can export your changesets with
hg export kernel-import:tip
What you probably want though is just the difference between what is the latest tip of the tree and where you imported. Use the diff command to get this
hg diff -r kernel-import
Now continue your work in the update tree you just created. Commit as much as you like doing all the development you require
You can use the export from the tag you created to the tip at any point to get all your changes against the underlying upstream.
Eventually you will need to re-sync with upstream again. At this point repeat the process; make a new update tree and pull your working tree into it. Archive the old working tree and continue development on the new 'update' tree.