Hi Paul, I've just updated a number of command line manuals to incorporate Firebird 2.5 and I have committed them to the normal manual module. So far so good!
> - 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. I'm not that fluent in cvs I'm afraid, so probably best I give this one a miss. It's screaming out for "human error" with all that switch, tag, merge, update - or whatever. (See, I'm confused already!) > - 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. This too is asking for problems I suspect. Too many humans involved for smooth running! > - 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. I like blunt and I don't care what the cvs gurus think! ;-) This sounds by far the method most likely to cause the least errors! I think I'll be sticking with this option. Now, how do I check out the b_release branch please? > Oh, and in all cases: don't forget to build and upload the HTML and PDF :-) What is the process these days? I had just got used to SCP'ing everything to the right place and "they" went and changed the web site. Last I heard was that we didn't yet have a process that was documented. > 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. Hmmm. I was always of the opinion that you "never broke the build" - so half updated documents were "ok" as long as they built. Things that don't build are not acceptable. I only ever commit fully buildable documents. Cheers, Norm. PS. If you let me have the full process for doing options 1 and 2 above (tag/merge/update/whatever) and the process for uploading html and pdf files to the new website, I'll happily test and then update the Doc Writers' manual(s) as appropriate. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Firebird-docs mailing list Firebird-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-docs
