Re: tag vs. rtag
On Sat, Jan 10, 2004 at 04:13:54PM +0100, Joachim Breitner wrote:
> Am Sa, den 10.01.2004 schrieb Colin Watson um 15:59:
> > I think I'm missing something. Why are you doing all this retagging?
> > Semantically, tags are not supposed to move once you lay them down,
> > although CVS supports a few means of getting round that in case of
> > mistakes.
> >
> > The debian_version tag really shouldn't be applied until you're just
> > about to make the upload.
>
> As far as I can see it, the cvsbuildpackage suite sets the
> debian_version_x-1 tag when you cvs-inject a package, or cvs-upgrade a
> package. Of course we could leave it where it is and only retag it just
> before upload, but we still would have to retag.
You run cvs-inject and cvs-upgrade with existing Debian source packages,
which presumably represent now-immutable versions of the package, so it
sounds like the right behaviour for it to tag it. As I understand it,
you're not supposed to use these programs for work in progress, though;
just use cvs as normal, without tagging. Don't construct source packages
and then import them into CVS with cvs-upgrade - that's far too
laborious.
> Also, cvs-buildpackage expects a debian_version_x-y tag corresponding to
> the version in debian/changelog, so you have to retag every time you
> build with cvs-buildpackage.
Either 'cvs export' yourself (without specifying a tag with -r) and
dpkg-buildpackage or debuild in the resulting directory, or just build
straight from the CVS working copy if that doesn't break your package's
build system. I build all my packages from Subversion working copies,
which isn't exactly the same but is the same principle. Some people
prefer to export first.
> Maybe I just didn't get it, then I'd be glad if you could show me the
> right way.
When working in CVS, tagging every time you want to do a test build is
definitely not what you want. For starters, you should be testing things
*before* checking them in, not afterwards. This is why I always make
sure that I can build packages from a working copy, since that allows me
to make a change, test a build, then commit with the minimum of fuss.
If some tool discourages that practice, then don't use it for test
builds; only use it for final release builds. Tags are for when you make
a release, when you want to mark some other point in the history of the
package, or when you want to branch.
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: