On 08/02/11 13:52, James Westby wrote: > On Tue, 08 Feb 2011 08:00:25 +0000, Max Bowsher <m...@f2s.com> wrote: >> Therefore, what about checking in the patched code, without any quilt >> metadata (.pc dir) but with a flag file that triggers bzr-builddeb to >> write out the appropriate metadata whenever a working tree is built for >> such a branch? >> >> (Writing out the metadata would consist of copying the series file to >> .pc/applied-patches, and reverse-applying each patch in reverse order, >> stashing the resultant modified file in .pc/<patchname>/<filename> for >> each patch) > > This would work for checkout. What are the implications for merge etc?
On consideration, the implications for merge are not pleasant. You'd need to quilt pop -a, merge the upstream (despite now having local modifications from popping), resolve conflicts, don't commit, quilt push, resolving conflicts in pushing the patches, and finally commit. Yuck. So, now I've realized the above, I'd go so far as to suggest that there is no reasonable branch format in between "patches as quilt series, *not* applied" and "full loomification". I think we should go ahead and change the package importer _now_ to revert to importing 3.0 (quilt) source packages with patches *not* applied. When it does so, it should probably write a "debian/source/local-options" file containing "unapply-patches". This will give us import branches that are actually usable for UDD-style development *now*, which I think we currently do not have for 3.0 (quilt) packages. Once the problems surrounding ubiquitous looms have been solved, we can think about switching the import format again, but at least we will then have usable UDD between now and when we reach that point. Max.
signature.asc
Description: OpenPGP digital signature
-- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
