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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
