> On Thursday 07 June 2007 21:59:27 Toshio Kuratomi wrote:
> > 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>
I wonder. What are we trying to do here?
1) Make hacking on a stack of patches easier
2) Make it easier to re-base - i.e. new upstream tarball, re-generate
each of the patches against the new upstream, resolving any
conflicts
3) Allow someone to fork a set of patches? e.g. OLPC has their own
version of a package with an additional patch, but wants to keep
in sync with the Fedora version of the package
I'd suggest quilt as a nice simple tool for (1). Stacked git (stg)
looks like it makes sense if upstream uses git.
The pain point with (2) which quilt doesn't solve well is resolving
conflicts. But diff3 style merging is all that's needed there.
We could solve (3) by managing patches in an SCM with something like
stg, but it might turn out to be too complicated to be useful.
> > 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?
Not really. The way to cherry-pick for upstream is to re-order the
graph so that the patches you want to upstream are first in the graph.
But the graph can't be ignored when cherrypicking.
Cheers,
Mark.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
