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
