Joachim> Not being able to modify stuff outside of debian/ is considered
Joachim> a feature by some :-)
+1. If I dget a package I've never looked at before, it's much easier
for me to understand Debian-specific patches if they are coherent and
commented in debian/patches, than if they are applied directly to the
John> I was forced to abandon [Darcs] due to all the conflicts it
John> generated. Eventually, its merge-in-exponential-time problem
John> became so severe that it became unusable.
This has significantly improved in Darcs 2, as long as you use the
darcs-2 repository format introduced in 2.0. Note that it only became
the default for new projects ("darcs init") in 2.2.
Joachim> I made the same experience when packaging xmonad. I think that if we use
Joachim> darcs (which would be worth a try), we should not try to mix it with any
Joachim> upstream darcs repository – just import upstream from the released
Joachim> tarballs. Or just keep debian/.
+1. My experiences trying to maintain the Darcs debian package as a
branch of the upstream repository have been unpleasant. I think this
was primarily because I imported a .diff.gz (from before I took over the
package) which created an ongoing whitespace conflict in configure.ac.
Joachim> I’m inclined to favor Darcs and tracking only debian/, extending
Joachim> debcheckout and darcs-buildpackage to handle the debian/-only tracking
Joachim> and see if it works out ok.
+1. Darcs' slowness and conflictiness seem to be improving a faster
than git's UI, but I admit I'm a biased observer (though I use both) :-)