Re: What to do when new version available upstream...
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
Reply to: