Ian Jackson <[EMAIL PROTECTED]> writes: > I think this is the root of the key difference between the `like patch > systems' people and the `hate patch systems' people.
In my experience, the key difference between whether or not I want to use a patch system like quilt is whether I have an upstream to which I need to feed self-contained patches that may go unapplied for extended periods of time. When I'm in that situation, I need to maintain that separate change in a self-contained file into which I can put notes about the status of merging with upstream and which I can forward-port *as an independent change* to new releases of the upstream software so that I can then push it to upstream again. It's possible that some of the revision control packages can do this, but an advantage to using quilt is that its resulting artifacts are in a very simple and easy-to-see form that other people working on the package can maintain and that I can easily mail to upstream or copy to a web page without having to script something inside the revision control system. I find this useful. I currently maintain some packages in this situation with quilt and some packages in this situation with svk letting the revision control system do the work. I've found that, in the latter case, I end up having to extract the patches out of svk and store them separately *anyway* in order to do upstream merges, and in general svk makes me less happy than quilt for every operation except merging with a new upstream release. On the other hand, it makes me fairly happy when doing the latter. I'm not sure if the tradeoff is worth it. After every upstream merger, I have to review every patch applied to the package *anyway* to make sure that it's still sane, and I find that easier to do by reading through the contents of debian/patches than by running filterdiff on diff.gz and then trying to work through the intermingled results of multiple changes. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
