[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: CVS problem



On Wed, 2005-06-08 at 11:09 -0400, Paul W. Frields wrote:

> In light of the pace of these changes, and the fact that there are more
> on the horizon, I think we should re-examine requiring people do
> separate checkouts of a docs-setup module.  I believe Karsten agreed
> with me, so he can pitch in here if desired.  It would be great if the
> docs-setup/ stuff simply came down on the same level with the my-
> tutorial/ folder, rather than subordinate (my-tutorial/docs-setup/),
> since the latter implies multiple redundant copies for people working on
> lots of docs.  Focus should be on ease of use for the user (who is not
> necessarily a developer), maintainability, and maybe other factors I'm
> forgetting.

I think I prefer docs-common as a module name, so will refer to the
common files directory that way.

There are a few ways to do this:

A) docs-common is worked with as being on the same level as all other
document modules, and calls to it are relative --> ../docs-
common/fedora-entities-en.ent

B) docs-common is subordinate to the document modules and is pulled in
during the initial checkout --> foo-tutorial/docs-common/

The major problem with option B is that it makes it harder to do
customizations in your local sandbox.  Everytime you cvs up your foo-
tutorial module, it will update docs-common.

However, it is awfully convenient to update with one step.  You don't
have to think about it to have the latest common files.  This also works
for the initial checkout, you get the common files without asking
separately for them, they are just brought in automatically.

Using option A we can still make the common module be pulled down
automatically, aiui.  However, the module being at ../ will protect it
from being updated when you don't intend to.

This adds the step of needing to find out about changes to the common
files and updating docs-common/ separately.

A third option is to not have a standard but do each module differently,
depending on how the author(ing team) wants it.

This means some of us would have ../docs-common and some would
have ./docs-common.

This might reduce portability of writers and some XML between modules.
Confusing running two processes.

I see the options being:

1) Easier and less flexible -- foo-tutorial/docs-common/
2) More steps, more flexible -- foo-tutorial/ and docs-common/ on same
level
3) Harder and more flexible -- 1 or 2 depending on the tutorial

- 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/

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]