On Sat, 2006-01-14 at 06:58 -0600, Tommy Reynolds wrote: > Hello, Folks! > > I just realized that when CVS tagging a document revision, it is not > sufficient to tag only the document directory: one must also tag the > building infrastructure in "docs-common/". Tags are fast, cheap and > easy, so we can use as many as we like. This is not a disagreement, just a contrast with a few things I've seen (admittedly very few, CVS newbie that I am). Lots of tags can make for a messy 'cvs status -v *'. OK, that's fine, but an usage of tagging at a directory root with default recursive behavior can mean many files being tagged that are not involved in the tag. That can be a bit confusing, aside from pulling in extraneous stuff for the checkout. So, imagining that everyone is tagging content in docs-common with each tag ... and you are correct, that is necessary to make it work tagging work ... oy, vey! It makes my brain hurt. Is this just what happens in a CVS repo over time? I used a proprietary SCM for a while (Perforce) that gives *each* check- in a unique, sequential ID. You can not only refer to them by ID, just like we do with bugzilla reports, but that ID is also a tag of that check-in. It is representative of the entire repo at the time of the ID creation, and you can just get the pieces you want. SVN do that by any chance? > Using a command such as: > > $ cvs tag <some-tag-or-other> docs-common example-tutorial > > will make it easy to reproduce a document any time in the future. > > Here comes my question: > > Since tags will be shared among all documents that use > "docs-common/", how should tags be formed? There has been a tradition of using ALL-CAPITALS. Sopwith requested that they be explicit, so we've been using e.g. FC-5-TEST1-TRANS-FREEZE, FC-5-TEST1-LATEST, etc. > Perhaps something such as "cvs tag example-tutorial-foo docs-common > example-tutorial" where the "foo" is up to you. A tag can get > project-wide, "example-tutorial-FC5_test2", or very local, > "example-tutorial-corrected-typo". Ah, interesting, include the module in the tag. That means you can use grep to sort out just the tags that are meaningful to you. I think having the module exactly like the module name (lower case), and then the data in ALL CAPS might make it easier to visually parse the information. release-notes-FC-5-TEST3-LATEST-WEB-SNAPSHOT installation-guide-FC-5-TEST3-BETA-UPDATES Let's discuss this some more. :) - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
