CVS tag naming conventions

[Jeff Fearn]

On Sat, 2006-01-14 at 12:45 -0600, Tommy Reynolds wrote: 
> Uttered Karsten Wade <kwade at redhat.com>, spake thus:
> 
> > > 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.
> > 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.
> 
> Er... snapshotting the status of _all_ the files in the resources
> directories is exactly the goal, isn't it?  
> 
> One tag == one environment.
>  
> > 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.
> 
> Durn tootin!  The "cvs log" and "cvs status" commands get ugly
> quickly, but I don't use them much ;-)
>  
> > Is this just what happens in a CVS repo over time?
> 
> Yup.  That's just how CVS works.
>  
> > 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?
> 
> Yes, others SCM's use a "change-set" property for exactly that
> purpose.  AFAIK, cvs(1) just does not have that capability other than
> the "tag"; at least the tag can be nearly anything that does not look
> like a revision number.
>  
> > > 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.
> 
> OK by me, but no wonder your brain aches from looking at a long tags
> list in capitals ;-)
>  
> > > "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.
> 
> Yup.  Not an accident.  When we tag "docs-common/" along with the
> document directory, we need a tag namespace rule to avoid collisions.
>  
> > 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.
> 
> If you don't mind BEING SHOUTED AT ;-)
>  
> > Let's discuss this some more. :)
> 
> I'd like to hear from someone with heavy SVN experience; I'm only an
> egg.

The SVN approach to this would be to create a new TAG, which is a
snapshot. Peeps would then checkout this new TAG. Basically this is a
cheap form of branching. trunk is svn's equivalent of cvs's HEAD.

svn copy http://server/repos/mydoc/trunk
http://server/repos/tags/mydoc/SNAPSHOT1.2 -m "Snapshot for 1.2"

Then others would 

svn co http://server/repos/mydoc/tags/SNAPSHOT1.2 SNAPSHOT1.2

Each book could be copied over to SNAPSHOT1.2 as it is finished.

You can enforce read only status in the tags directory which would
prevent updating those files. You can do that on a per user basis, so
last minute changes could be added if the "right people" thought it
necessary.

Note that in SVN I think the capitalisation adds nothing and is
WRONG! ;)

-- 
Jeff Fearn
gpg fingerprint:5FB4 61C4 8BE3 4DF6 F7FD  37B0 95C3 0F36 21DC 65C6

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/docs/attachments/20060116/3f4f27b7/attachment.bin