Hi Norman, >> - 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. So am I! Of course, being the snob I am, I started out with the first option, but the yokel soon got the upper hand ;-) With 1 and 2 there's just too much that you mustn't forget, lest you'll find yourself in a terrible mess. > Now, how do I check out the b_release branch please? On the command line: cvs co -r B_Release GUI clients usually have a drop-down or text field where you can fill in the branch name. > > 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. You have to make a SSH connection to 78.47.172.253, account www-data. PDFs go into /var/www/firebirdsql.org/staticsite/pdfmanual HTML into /var/www/firebirdsql.org/staticsite/manual Both are symlinks. In reality, the PDF dir is /var/www/firebirdsql.org/docroot/file/documentation/reference_manuals/user_manuals, and the HTML dir /var/www/firebirdsql.org/docroot/file/documentation/reference_manuals/user_manuals/html I take it you don't have access yet? Please send your public key to Sergey Mereutsa; I've already asked him to add it to the www-data account when it arrives. > > 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. So did I. But during the transition, Dmitry rebuilt the entire docset, including a number of documents that were "in limbo", so to speak, with comments in the text, and symbols like ???? and ## Xxx where there ought to be version numbers or dates. That prompted the discussion which resulted in the decision to create a release branch. Everything committed to that branch (B_Release) must be *publishable* as well as buildable. > 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. Let's forget 1 and 2, unless someone insists on using them. Cheers, Paul Vinkenoog ------------------------------------------------------------------------------ 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
