On Thu, 2007-06-07 at 21:18 -0400, Jesse Keating wrote:
> <strawman>
> We have two things for the upstream in our package SCM. We have the prestine
> tarball stashed away in a lookaside, and we have an exploaded tree of the
> source. We use the exploaded tree of the source to manage our patches to
> that source and to help with rebases. However the patches we manage always
> apply to the prestine point. At package build time, the patches we manage +
> the spec file + the prestine tarball stashed away are combined to make an
> srpm, and that is shoved through the build system.
> </strawman>
>
So I see two ways to store patches:
vendor-branch
|
|-- Foo.patch branch
|
|-- Bar.patch branch
Foo.patch and Bar.patch both directly apply to the upstream vendor
branch.
vendor-branch
|
|-- Foo.patch branch
|
|-- Bar.patch branch
Foo.patch is the first patch against vendor-branch. Bar.patch is
committed to the combination of vendor-branch and Foo.patch.
At first I was hoping to do the first way as it makes it easier to
cherrypick changes for upstream. However, it quickly became complex as
we had to manage a separate merge branch that was equivalent to the
second storage graph. Whenever we rebased we would potentially have to
remove conflicts from the second graph as well as the first.
So I decided that going directly to the second style was preferable.
That does not have the enhanced cherrypicking benefits to upstream but
it still allows us to work with individual patches within the VCS more
easily than when they were simply patches stored in CVS.
Do you see a way around this limitation?
-Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
