Re: [Quilt-dev] Question on integrating quilt with CVS

[Andreas Gruenbacher]

On Monday 15 November 2004 19:13, Thomas Vander Stichele wrote:
> Hi,
>
> I've been using quilt for over a year, and have always been very happy
> with it.
>
> Recently I tried upgrading from 0.21 to 0.32 and got bitten by some
> compatibility bugs.  Reading through the lists, it seems this is a known
> issue and was intentional.  I worked around that by going to the old
> quilt, popping all patches on all projects, then install the new one.

No, upgrades should work meanwhile. Can you easily reproduce the state from 
before the upgrade? Can you send me an example (the smaller the better)? 
Thanks.

> Today I ran into a more serious problem.  For one subproject of
> GStreamer, we track an upstream CVS checkout and put patches on top of
> it.  The upstream CVS checkout is a subdirectory inside a bigger module.
> The bigger module has a working autotools setup.  The upstream checkout
> has all the quilt patches applied and all quilt state commited to cvs as
> well (so all .pc stuff).  You may wonder why :)
>
> The reason is simple - I wanted to provide this bigger cvs module in
> such a way that:
> - normal users checking out from cvs have a working state representing
> our patched copy
> - developers that want to work on the quilt patches can pop and push
> patches, and then commit both patches, state, and the changed source
> tree to CVS
>
> Arguably this is a particular requirement.  Anyway, with 0.21 this works
> out perfectly.

This really is not such a great idea. I would rather put the unpatches sources 
and patches in the CVS, and add a script that applies all patches (or even 
README). Putting the quilt meta-data into CVS just is needless overhead.

Alternatively, you *may* want to put the patched sources in the CVS, plus 
reverse patches. Then applying those patches would amount to removing the 
original patches. I have never tried that, and such a system may be hard to 
work with. Another option we might have: We could teach quilt to 
reverse-apply patches by default (e.g., -R in series.conf). Then the patches 
would apply to the unpatched sources. The one drawback I see here is that 
patches do not always reverse apply, or reverse apply correctly, so people 
would get bitten once in a while. Increasing the number of context lines 
would help most of the time, but it would still be a major hack.

> Now, with 0.32, when popping patches, quilt starts removing all of the
> CVS/ administrative dirs and files from the project source tree, which
> causes the pop to fail.  Previously these CVS directories were ignored.

Quilt did remove its meta-files all along. The scenario you describe could 
only ever have worked when all patches were applied at time of the checkin. 
Quilt never touches anything that's not contained in the patches themselves 
though (except the .pc directory). If the CVS files are included in the 
patches they will get modified; otherwise they won't.

> This means that I cannot find a good way to integrate quilt in our setup
> while still satisfying the goals outlined above and allowing us to
> separate patches so we can send them upstream.
>
> Now the questions -
> a) I've seen some mails wrt. CVS integration in quilt, and some people
> have hinted at that they didn't even need it because they also work well
> with CVS.  Anyone care to explain exactly how they work so I can get
> some more ideas ?

Unpatched sources + patches.

> b) What exactly changed that causes the patches to fail now with the
> newer version, while it worked fine with the older version ?

I hope the above answer is already enough so you can figure out what exactly 
fails.

Cheers,
-- 
Andreas Gruenbacher <address@hidden>
SUSE Labs, SUSE LINUX AG