HOWTO: Accessing re-organized Fedora Docs CVS

Karsten Wade kwade at redhat.com
Tue May 10 22:56:35 UTC 2005


On Tue, 2005-05-10 at 16:58 -0500, Tommy Reynolds wrote:
> Uttered "Paul W. Frields" <stickster at gmail.com>, spake thus:
> 
> > shared			xsl common stylesheet-images css scripts
> > 
> > my-module		my-module shared
> > 
> > 
> > Let's keep in mind the usability aspect.  When someone does a "cvs up,"
> > they should receive any updates to css, xsl, etc.  The method above
> > assures that, and knocks out the requirement to separately download
> > supporting stuff.  By diverting all the supporting modules into
> > "shared," any changes to anything *in* "shared" (including adding
> > another dir later) will automatically come down to people running "cvs
> > up".  Is there a reason this is not acceptable?
> 
> I object to having [potentially] several copies of the common stuff
> under each document.
> 
> As long as common directories are peers of the working document (read
> that as "../common") you are going to need a separate "cvs update"
> command because there is no longer a "CVS/" peer directory to them
> for one-stop-shopping.

OK, that's clear then.  If we want them to be common inclusions of a
single module, they need the CVS/ peer directory, so have to be included
within the module itself.

> Either we stay with the current setup, or we go in and do surgery so
> that documents expect the common stuff as subdirectories.
> 
> Since it's a style issue, I don't feel justified in saying one is
> technologically better than another although for a software development
> project I know what I'd choose.  Just pick one and let the edits fall
> where they may.

Or are you thinking of a way where we pick both, dependening on the
writer's preference?

- Karsten
-- 
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint:  2680 DBFD D968 3141 0115    5F1B D992 0E06 AD0E 0C41   
                       Red Hat SELinux Guide
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
-------------- 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-dsco-list/attachments/20050510/63c563f0/attachment.sig>


More information about the fedora-dsco-list mailing list