On Fri, Dec 17, 2004 at 03:21:10PM -0500, Colin Walters wrote:
> First, I think it's wacky to maintain patch files in revision control.
> If you want to look back at history, you're looking at a diff of a diff,
> which is just incomprehensible. The right way to do this in my opinion
> is to have each patch be a direct branch of the upstream source. If you
> have patch interdependencies, then you create a new branch which merges
> from the interdependent branches, just like how you have to adjust the
> patch files now.
That's an idea that I've been playing with myself. However, I want to
be able to generate SRPMS from it too, preferably generating the PatchN
series of patches. Problem is that with PatchN you have an ordering for
the patches, whereas with the direct branching from the upstream source
you don't. And I don't quite see how a new branch for interdependent branches
would work in practice.
However, I think we can avoid all sorts of problems, if instead of branching
from the source, we branch from the brances -- this would give us the
ordering. So, say that now you have a package 'foo' that has 3 patches in
its .src.rpm:
Patch00: disable-bar.patch
Patch01: bluecurve.patch
Patch02: memleak-fix.patch
We can then branch as follows:
foo -- branch for tracking upstream source
|
\-disable-bar -- branch for the 'disable-bar' feature
|
\-bluecurve -- branch for the 'bluecurve' feature
|
\-memleak-fix -- branch for the 'mem-leak' feature
This should be enough to be able to automatically generate the correct
patches, and build the SRPM, no?
It does make it a bit difficult to change the order of the patches, but
it can be done, and to be honest, I don't see this sort of reordering as
a common occurence.
--
Dimi.
