Menu
▾
▴
Re: [generguide-devel] <xinclude> links
|
From: Sean W. <se...@ya...> - 2003-09-14 10:10:37
|
----- Original Message -----
From: "Cameron Shorter" <ca...@sh...>
Sent: Sunday, September 14, 2003 1:09 AM
> On Saturday 13 Sep 2003 9:53 pm, Sean Wheller wrote:
> > If CVS is managing the files and their versions.
Why
> > add to the path with a
> > version number? If a version is required, could it
not
> > be included in the
> > file name. This way regardless of the file
location,
> > the version number will
> > always be known.
>
> I envisage that there will be multiple
GenerRepositories. Each repository
> will be independantly administered from each other,
putting out their own
> releases of guides relevant to their area of
expertise. Each repository
will
> issue releases which reflect updates. Both new and
old releases need to
be
> accessable via the web by other projects.
>
> So, if I am creating a Developer's Guide for the
Linux Documentation
Project,
> I may reference the Sun Java Coding Standards
(maintained by Sun).
>
> There are 2 types of guides I may want:
> 1. A guide that doesn't change over time. I'm
developing a product which
is
> not going to upgrade it's toolset, so I want my
Developer's Guide
> configuration to always reference Java 1.4 docs. So
I reference release
4.0
> of the Sun's GenerRepository.
>
> 2. A guide that always refers to the latest
development practices. So I
> reference the head release of Sun's GenerRepository.
>
> Does this make sense?
Ok, I think I get the picture. At the end you see
people referencing only
the head, hence you want version control in both the
path and file level.
When a new version is released it is copied to a new
repository. The
previous version then remains in its final state and
is not touched. That
way the integrity of my reference to a file in the
head of the previous
version will be preserved. The head will always remain
the head, from a
given date when the new version was started.
While this is a solution, I think we will have
additional overhead and
duplication of content between versions. I am not sure
that this is needed.
Horizontal Thinking.
A file is created called blue.xml. The file is
modified and a new version
exists. We now have two files in CVS, blue_v1.xml and
blue_v2.xml
A file is created called red.xml. The file is modified
and a new version
exists. The file is again modified and a new version
exists. We now have
three new files in CVS, red_v1.xml and red_v2.xml and
red_v3.xml
Horizontally all files increment a version in this way
until the release. If
no more changes are made we have a total of 5 files in
the CVS for our
release.
Vertical Thinking.
release 1 = blue_v2.xml and red_v3.xml
Now lets move ahead a few releases.
release 2 = blue_v2.xml and red_v4.xml
release 3 = blue_v2.xml and red_v5.xml and
yellow_v1.xml
release 4 = blue_v2.xml and red_v5.xml and
yellow_v2.xml
release 5 = blue_v2.xml and red_v5.xml and
yellow_v3.xml
By the pattern you can see that if we were to create a
new repository folder
for each version, then the file blue_v2.xml would
exist in duplicate 6 times
and red_v5.xml 3 times. Subsequent releases would
further increase
duplication is the files are not incremented a version
because of some
modification.
In a book I need version control not only of the
included XML Instances, but
also of the book itself. However, I do not need to
always have a new or
duplicate copy of the files. In the example below " "
is used to represent
use of a file from the previous release.
Book 1 = release 2(blue_v2.xml, red_v4.xml)
Book 2 = release 3(" ", red_v5.xml,
yellow_v1.xml)
Book 3 = release 4(" ", " ",
yellow_v2.xml)
Book 4 = release 5(" ", " ",
yellow_v3.xml)
Book 5 = release 6(" ", red_v6.xml,
" ")
Book 6 = release 7(" ", " ",
yellow_v4.xml)
All files exist only once in their final release
state. A book may use any
file from any release.
Book 7 = release 8(" ", red_v4.xml,
yellow_v5.xml)
red_v4.xml was from release 2, but if the author finds
the content in
red_v4.xml to be better suited, it may be reused in a
future book, this case
Book 7.
Note that each book remains in version control as do
all the files.
Flexibility is great, content reuse optimised.
I don't know enough about CVS at lower levels to say
if this is possible,
mainly because I always refer to the head. But it is
apparent that the head
itself is made of files with varying ages and as with
Book 7 it may or may
not present a problem. To the current author of Book 7
it is not a problem.
To a future author it may be a problem as red_v6.xml
will not be known. The
collaborative environment presents many challenges.
Certainly I would like to have the ability to discover
all content.
Investigate its lineage and select a version that best
suits my
requirements. Used it unaltered or modify it to a new
version. If I modify
to create a new version of red_v5.xml, I cannot name
the file red_v6.xml it
would have to branch at red_v5.1.xml. My version is
then free to discovered
and used by other authors.
The permeations of this theory can spin our heads for
a year. So I ask the
question. Is CVS the tool for the job? Perhaps we need
CVS and an XML
Database, maybe just the database with an application
layer above it. CMS
and KMS? What tools do we recommended and what tools
do we use.
Sean Wheller
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
|
