Hi all, If you have write access to the manual module, please read this message carefully.
Yesterday, I have created a CVS branch called B_Release. This branch is intended for all the *published* (or at least *buildable and publishable*) revisions of our documents. The idea is that, for most of the time, we keep on working like before. We edit manuals and other files in our working copies, and commit to CVS whenever we deem appropriate, even if the document is in an unpublishable state. All these commits are automatically done to HEAD (the tip of the default MAIN branch, or trunk). However, as soon as a (new version of) a document is published, we must also commit it to the B_Release branch. This can be done in several ways: - If you're fluent in CVS, you can first commit to HEAD, tag the file(s), then switch your local copy of the file(s) to B_Release, merge in the differences made in MAIN since the previous merge (which you should have tagged as well) or since the branch point, commit to B_Release, and switch back to MAIN. - You can also (just once) check out a second working copy, specifying the B_Release branch. You work in your main working copy, but after committing a publishable version, you go the the B_Release working copy, and update, merge and commit. This too requires tagging like in the previous example. The difference is that now you have two working copies: one of MAIN, and one of B_Release. Within these working copies, you don't switch files back and forth between branches, and you don't risk to accidentally leave a file on another branch than where you think it is, or to tag a file on the wrong branch. - The third way is not very subtle, and frowned upon by CVS gurus, but very robust (in our case!): You have two working copies like above. You work in the first one (the trunk). When you're going to publish, you bluntly copy the file(s) in question over their counterparts in the B_Release working copy, and commit there (of course you also commit to HEAD). The advantage of this method is that now you are absolutely sure that the revision in B_Release is identical to the one in HEAD. You can't make subtle mistakes while merging, because there's no merging and tagging involved. You just bulldozer your way into the B_Release branch and drop your stuff there. Oh, and in all cases: don't forget to build and upload the HTML and PDF :-) The advantage of all this: The B_Release branch always contains the latest publishable revision of every document. So if ever we have to re-upload any manuals, or even the entire set, all we have to do is build them from B_Release and we're fine. At the same time, we can commit as often as we want without fear of breaking any builds. To be continued... Cheers, Paul Vinkenoog ------------------------------------------------------------------------------ 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ _______________________________________________ Firebird-docs mailing list Firebird-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-docs
