Hi Stephane, On Mon, Mar 01, 1999 at 04:05:43PM +0100, Stephane Bortzmeyer wrote:
> "Using CVS together with Debian GNU/Linux packages" > <http://www.debian.org/devel/HOWTO.cvs> suggests another solution, based > on CVS. It seems very nice (I use CVS for other projects) but I did not > use it for Debian yet (any experiences/war stories?). I use for almost all of my pacakges. cvs-buildpackage is a VERY nice front end for managing pacakges via CVS. So far, I've been bitten by only one problem, namely: $ cvs-inject foo_3.1415-1.dsc this puts foo 3.1415 in a branch (source-dist) and 3.1415-1 on the main trunk. Later, when foo 3.14159 comes out you do: $ cvs-upgrade foo 3.14159 which will put foo 3.14159 in the source-dist branch, and tag it as upstream_version_3_14159. So far, so good. $ cvs co foo will check out the latest version on the main trunk (i.e., the debianized version). $ cvs co -jupstream_version_3_1415 -jsource-dist foo will check out the lastest version on the main trunk and merge the changes made upstream between 3.1415 and 3.14159; here's the catch: if 3.14159 renamed some files (something I've encountered a number of times), the checked out version will contain the files present in 3.1415 and the new files in 3.14159. You have to delete them by hand (am I missing something obvious here?), I usually do _something_ like this: $ cvs ex -d foo-3.1415 -r upstream_version_3_1415 foo $ cvs ex -d foo-3.14159 -r upstream_version_3_14159 foo $ ( cd foo-3.1415 && find -type f | sort ) > foo-3.1415.list $ ( cd foo-3.14159 && find -type f | sort ) > foo-3.14159.list $ diff -u foo-3.1415.list foo-3.14159.list | grep ^- this will print a list of removed files, which I feed to "cvs rm -f"; I also get a list of added files that's fed to "cvs add". I've canned all this into a script that I'd like to clean up (it's very specific to my setup) and submit as a wishlist bug against cvs-buildpackage (but don't hold your breath on this!!). After all of this, I check the output of "cvs -q -n update" for conflicts and modified files, update debian/changelog, update debian/rules if necessary, and then test build the package, and then I do "cvs-buildpacakge -F" and that's it. With this setup I've cut down the time required to update pacakges by at least 50% I was bitten by this when I wanted to inject 10-15 releases of certain package into the CVS repository. The package is pathological in the sense that it kept moving, renaming, removing and readding files for at least four releases. I didn't notice at the moment, and when I upgraded the package, it got all sorts of cruft added in the .diff.gz; the size of the diff didn't struck me as odd because I had heavily patched the sources -- later I checked what was going on, and surprise surprise, I was including all sorts of old files in the patch. After that I learned I had to be more careful, but recently I managed to screw up again under the very same circumstances. I had forgotten cvs-inject has a tendency to do that. I guess I need my own version of cvs-inject for this purpose. But all in all, that's all the problems I have had. cvs-buildpackage is very nice, you have to change your way of thinking a little bit (for example, building _in_ the CVS working directory doesn't get along with "for f in *"), but it's a real time-saver. The only other problems I've found so far is the usual CVS stuff (symlinks and CVS don't like each other, keyword expansion, etc), but if you use CVS you already know how to deal with that. Marcelo
