Goswin von Brederlow dijo [Tue, Apr 28, 2009 at 12:48:58AM +0200]: > Hi, > > I recently converted a few quilt using local packages to the new 3.0 > (quilt) format. Additionaly those packages are kept in an RCS > (mercurial here). Now the problem is: How to version control them? > > The new format allows one to just edit the source and build it. No > creation of patches neccessary as dpkg-source creates them for you. > Obviously it is a good idea to give patches a descriptive name instead > of debian-changes-version but that is easy enough to do after a test > build. The ease of creating new patches is just so much fun. > > But how/what do I add and commit to the RCS? > > 1) everything > (...) > 2) only unpatched sources + debian > (...) > Currently I think the second option is more sane. What are your > thoughts?
I believe having each patch as a separate, trackable and self-described entity is better. I maintain several packages, both on my own and as part of a team work. Whenever there are modifications to be made to the upstream sources, I prefer storing them as quilt patches - Not as changesets (or feature branches or anything like that) on my VCS. I value having them as understandable units in my source package, in case I go missing or somebody wants to understand it by only checking there. Yes, I know I could describe the package should be cloned from a given repository in my README.source, but I do feel it is much clearer if the source package has the complete information, and the VCS-based packaging has only the packaging evolution over time. ${vcs}-buildpackage scripts keep your base directory clean, so I don't see it as a huge administrative penalty to keep my patches in debian/patches. Yes, I have to apply them in order to work on one of them, but debian/rules clean takes care of leaving everything ready for a clean build. -- Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org