|
Size: 1551
Comment:
|
Size: 2649
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 47: | Line 47: |
| === 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, so you can easily refer to just your changes later {{{ hg tag upstream-merge }}} |
|
| Line 49: | Line 73: |
| Your changesets should now be on the the tip of the update tree (XXX: is that right?). So the update tree becomes the new working tree, and you can archive the old working tree. | 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. |
| Line 54: | Line 78: |
| hg export tip | hg export upstream-merge:tip |
| Line 56: | Line 80: |
== 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. |
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.
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, so you can easily refer to just your changes later
hg tag upstream-merge
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 patches (for sending to lists, etc) with
hg export upstream-merge:tip
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.