[Quilt-dev] Re: quilt

[Andreas Gruenbacher]

Hello,

I have removed lustre-devel from the CC; hope that's okay.

On Wednesday 23 July 2003 17:22, Peter Braam wrote:
> On Wed, Jul 23, 2003 at 12:42:27PM +0200, Andreas Gruenbacher wrote:
> > On Wednesday 23 July 2003 01:59, Peter Braam wrote:
> > > Secondly also in Makefile.in I
> > > do not install the doc/README file because it confuses RPM.
> >
> > What exactly consuses RPM? Is it the doc/ directory? The README contains
> > information that is very relevant for starting to work with quilt, so I
> > think we want to keep it in the RPM.
>
> Of course we want it- RPM automatically picks up %doc files.  Installing
> them (in the wrong directory that didn't include the version) isn't
> necessary, and let to the complaint that rpm found an "installed file which
> is not in the RPM".

I still don't understand what exactly was wrong. I know that RPM4 complains 
about files not in the file list, maybe that was the only issue.

> [...]
> > >   3. We fixed combine-series because combinediff is broken, remember. 
> > > We introduced the ~orig files the first time a file was patched, to
> > > make aggregate diffs.
> > >
> > >      Quilt's has a diff option that could in principle combine the
> > > series, but I'm worried it may not quite work yet.  Can you add a
> > > "combine" command to quilt, that mimicks our combine-series command?
> >
> > What's the difference betwen combinediff and what can be done with `quilt
> > diff' already? If `quilt diff' is broken (which I don't believe), I'd
> > much rather like to fix it instead of adding a new command that does the
> > same thing under a different name.
> >
> > >      You could also make this an option like quilt diff -a (i.e. diff
> > > totally everything in the series, or diff everything up to the current
> > > top patch).
> >
> > That would be a convenience option to the `-P' and '-c' options of `quilt
> > diff'.
>
> To avoid a lot of typing I need something like quilt diff -a that creates
> one total patch from either all the applied patches or from all the patches
> in the series.  No further options, and in particular no typing of the
> names of patches should be necessary for that option.

Makes sense. Combining all patches in the series into one currently is not 
implemented (and would have to perform the equivalent of applying them all 
anyway). Combining all applied patches should work with `quilt diff -c-'. I 
forgot, and it was undocumented.

> There were two forms of breakage that we have seen in this scenario, but
> quilt may have neither problem, hopefully:
>
>   1.  concatenating patches allows them to be applied as a total patch. 
> But patch -R can break on such patches because it does not walk the patch
> backward.
>   2.  the combinediff program in patchutils was broken and did not always
>       produce a correct combined diff.

Quilt is careful to produce the equivalent result of applying all the patches 
to the tree and diffing against the original tree.

> It seems there are no objections to quilt diff -a as an experiment then.

Is `-c-' okay, too?

> > >   5. I'd like our forkpatch to become quilt fork <new-name>
> > >
> > >      Andreas, we use forkpatch when a patch that is shared by multiple
> > > series fails in some source tree.  We then do
> > >      forkpatch <name, typically  'next-patch + "forked-suffix"'>
> > >      pushpatch -f
> > >      refpatch
> > >      So this is to fix up a patch, but give it a new name.  I believe
> > > that with Andreas' quilt forkpatch is as simple as:
> > >
> > >        cp patches/`quilt next`.patch patches/<forked-name>
> > >        edit of the series file which we already have.
> >
> > That seems useful, but I'm not sure if this is the most efficient
> > workflow. You push patches until one rejects, then force apply the patch
> > that failed. Maybe the fork should happen inside `quilt push'. On the
> > other hand, the result of this isn't intuitive, either.
>
> "fork" is vital for our workflow.  Example:
>
> we have a patch ea-lustre.patch for EA's, which initially applies to
> linux-2.4.20.   When we move to linux-2.4.21 our workflow is:
>
> cp series-2.4.20 series-2.4.21
> cd /usr/src/linux-2.4.21
> quilt push ... repeat
> quilt push
>  --> error ea-lustre.patch doesn't apply
> quilt fork ea-lustre-2.4.21.patch
> quilt push -f
>  fix things
> quilt ref
>
> In this way we build the new series file. Admittedly without the pc files,
> it isn't such a big deal anymore, but this is really a nice work flow for
> what we do all the time.

Okay, agreed. Send a patch if possible, please. Rename is almost identical, 
btw.

> It would be great if quit could accomodate also calling into cvs (or
> another scm) to do:
>
> cvs add "forked patch"
>
> here.

I don't want to marry quilt with CVS. CVS's days seem counted; at least many 
people are using other SCM systems nowadays. Maybe we can implement some 
hooks that could then do the necessary SCM operations. Overall I don't like 
the while idea too much, though.

> > Would a simple `quilt rename' that renames a patch and updates
> > series.conf do?
>
> I would LOVE a quilt rename in addition, but it would be even nicer if it
> could also do
>
> cvs rm   "original patch"
> cvs add  "renamed patch"

Yes, similar to fork.


-- Andreas