Yes and no. I can, and will, provide all the help that it is possible for a
tool to provide. So I can make the question "what is in X but not in Y"
very easy to ask. You still have to pull the stuff from one to the other
and do the intergration.
How this is implemented is by using named lines of development - in your
case, that's likely to be overlapped but occasionally diverging LODs.
Suppose you have a copy of the tree that you have wacked into working on
architecture X (where X != Intel). Your tree has become both out of date
with the main tree as well as working for your architecture. So the last
thing you want is to resync with the main tree and have it screw up your
changes - is this a correct characterization of your problem? If so, the
answer is this:
Label the tree with a LOD of development when you start working on it (or
label it after the fact, which is harder because you need to know where you
started but still doable). Label basically amounts to sticking a funny kind
of tag, called a LOD tag, in the tree as of a certain point. Let's say you
called your LOD "X_arch" and you made that the default LOD (sort of like
a default branch in RCS/SCCS but it doesn't actually have to be a branch).
Let's suppose that the main tree is also labeled and that label is
"linux-dev".
Let's say a file in your tree looks like this
revs symbolic revs
1.1 linux-dev.1
1.2 linux-dev.2
1.3 linux-dev.3
and you stick your label on it, which implies the root of a new LOD so it
looks like
revs symbolic revs
1.1 linux-dev.1
1.2 linux-dev.2
1.3 linux-dev.3 X_arch.0
Now you add some work:
revs symbolic revs
1.1 linux-dev.1
1.2 linux-dev.2
1.3 linux-dev.3 X_arch.0
1.4 X_arch.1
1.5 X_arch.2
So now you resync with the main tree which has also added one revision so
the two versions look like this before the resync
linux-dev.1 linux-dev.1
linux-dev.2 linux-dev.2
linux-dev.3 linux-dev.3
linux-dev.4 X_arch.1
X_arch.2
The process of resyncing will glue those two together, forcing the X_arch
stuff off onto a branch like so
linux-dev.1
linux-dev.2
linux-dev.3 --\
linux-dev.4 X_arch.1
X_arch.2
At that point, you can decide several things:
1) I want to merge X_arch into linux-dev
2) I want to merge linux-dev into X_arch
3) I want to just keep on going with X_arch and ignore new linux-dev
4) I want to destroy the X_arch stuff and just use the linux-dev stuff
For you, I suspect that you will periodically want to suck over the
linux-dev stuff into the X_arch LOD so that you can stay up todate.
At some point, you are going to generate a series of X-arch patches that
will be submitted to the linux-dev LOD for inclusion.
Does this help?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/