> 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.
> >
> From: YC Chan
> Sent: Tuesday, July 03, 2007 9:17 AM
> To: dokuwiki@xxxxxxxxxxxxx
> Subject: [dokuwiki] Re: Best practices of multiple documentation
releases
>
> 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.
(This would be much easier if you would turn off HTML in your mail agent
and post your responses at the bottom where they belong.)
First, the diffs are automatically regenerated by any decent RCS when
you check in a revised file. Most of them also have tools to examine
those diffs which highlight the changes so they are easy to spot. It
shouldn't matter that you dropped all of the intermediate details. If it
does, maybe some of those details should not have been deleted.
I also believe 1.2.1 can not become 1.6 in this case. Because then
adding a feature to 1.5 becomes 1.7, and you now have seriously confused
two history threads. The diff between 1.5 and 1.6 backs out all of the
changes between 1.2 and 1.5, then the diff between 1.6 and 1.7 puts them
all back in with the new additions. This is what we are dealing with in
our conversion. Perforce won't import the branches from PVCS. The result
is likely to be a nightmare for several years. You don't want to go down
that road.
Bob McConnell
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
