[Fedora-xen] sparse-merge tutorial

[Juan Quintela]

On Wed, 2006-05-24 at 08:09 -0400, Aron Griffis wrote:
> Hi Juan,
> 
> Nice to meet you. :-)

Nice to meet you.

> Indeed this is much simpler!  I have some questions though:
> 
> 1. How are the linux-2.6-xen.hg and linux-2.6.tip-xen.hg trees
>    maintained?  Is 2.6.tip a port of xenlinux to linux-2.6 tip?

basically, linux-2.6-xen is on last (or almost last) linux-2.6.16.x
kernel based.

linux-2.6.tip-xen is based last linux-2.6 kernel.

But both of them are known te be get behind(once more, other less, as I
need a kernel that compiles on rawhide, and davej updates daily, I need
to update also daily).  :(  Normally my fedora kernel is updated every
morning.

> 2. How do you guarantee that you're matching versions with the fedora
>    kernel, since it is based on git snapshots?  I was using tip for
>    merging at first, but quickly ran into discrepancies.  For that
>    reason I'm using the exact same git snapshot now.

It has not been a _very_ big problem for me, because I commit on the
same tree than davej, normally the same day:)  i.e. basically what is in
its git version is the same that is on mercurial linux-2.6 that day.
And I have the advantage that I can do minor changes at commit time :)

> 3. How do you prevent pollution of the patch with non-xen files?  Your
>    method would seem to create a patch to update the Fedora kernel
>    beyond git11 (at present) to tip, but you must be handling it
>    somehow.  I imagine all the updated files would appear in the
>    xen diff, beyond those directly related.

That is the best part of it :)

linux-2.6 mercurial tree is almost the same than the git version that
davej is using (normally there is no problems at all).  Then I do:

hg pull -u ../linux-2.6-xen
hg pull -u ../linux-2.6

make changes until everything compliles & boots.

hg commit -m "merge with rawhide cset blah"
cd ..

diff --exclude-file=<path> --exclude=.hg linux-2.6 linux-2.6-fedora

As I am based on that tree upstream, by definition, any changes against
it are needed xen changes :)

> Thanks for your response.  The ia64 team is working fast... I hope
> we'll be able to merge with your work soon.

Just now, for each three I compile:

- i686
- i686-xen0
- i686-xenU
- x86_64
- x86_64-xen0
- x86_64-xenU

that means more work for me and getting ia64 & ia64-xen0 & ia64-xenU to
compile in each batch :p  I am gessing that I will have to get a
cross-compiler working at some point.

Later, Juan.