|
Size: 1249
Comment:
|
← Revision 10 as of 2012-10-25 20:12:08 ⇥
Size: 3287
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| <<Include(A:dated)>> <<Include(A:style)>> <<Include(A:delete)>> |
|
| Line 20: | Line 24: |
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 }}} |
|
| Line 46: | Line 62: |
=== Merge === 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 }}} == Continuing Work == 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. ---- |
Note:
This page appears to contain material that is no longer relevant. Please help improve this page by updating its content.
|
This page does not meet our |
This page is proposed for deletion. See our
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.
Clone Upstream
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
Clone Working
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
Update time
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
Merge
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
Continuing Work
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.