[dokuwiki] Re: Best practices of multiple documentation releases
- From: "YC Chan" <peter.chan.yc@xxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Tue, 3 Jul 2007 15:16:31 +0200
By 'frozen' I mean it was decided at that moment, contractually signed and
the software released.
It becomes 'history'. Following v 1.5 if the customer wants to change v 1.2,
well no problem,
but the next version becomes 1.6. There is no branching. Time is an endless
river ...
DB users always have a way to purge their db tables. 'Infinite' revision
control sounds beautiful but
I'm suggesting that we forget some details and offer Wiki users a way to
purge the pages from time
to time. The version tag is one way to do it, if we foresee enough 'fool'
guards.
If you make a copy of the namespace/or all the pages, you still foresake the
revisions. And you can't automatically compare your current release with the
official version tagged 1.X, and have to
print it out and checking line by line to find out the changes since a given
official version.
2007/7/3, Bob McConnell <rvm@xxxxxxxxx>:
But then what happens when a customer insists you back port a bug fix
from 1.5 to 1.2 that requires a change in the 1.2 version of that
document? You won't be able to branch and fix the 1.2 version because it
is frozen.
I think you really need to look into a true RCS system, like Perforce or
DARCS for this. Checking in the current content of the wiki would
automatically generate the diffs and you gain the full use of the other
features. Or convert it to PDF before checking it into the RCS.
Bob McConnell
(Currently involved in moving ten years of source and document archives
from PVCS to Perforce.)
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
Other related posts:
