CVS tag naming conventions

Karsten Wade kwade at redhat.com
Sat Jan 14 18:13:27 UTC 2006


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20060114/be6fd7a6/attachment.sig>


More information about the fedora-docs-list mailing list