Re: Centralized darcs
Ian Jackson <ian@davenant.greenend.org.uk> 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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: