On Fri, Jan 13, 2006 at 08:02:55PM +0100, Axel Wernicke wrote:
> >We include revision, date and author for only the *last revision*. This
> >is automatically filled in by CVS, once we added the code example listed
> >below. It'll look like this (using sect1 as an example here):
> >
> > <sect1info role="cvs">
> > <revhistory>
> > <revision>
> > <revnumber>$Revision$</revnumber>
> > <date>$Date$</date>
> > <authorinitials>romanofski</authorinitials>
> > <revremark></revremark>
> > </revision>
> > </revhistory>
> > </sect1info>
>
> OK, this directly leads to the question which elements we should to this for. Since there is
> no such thing in docbook as "pages", we have to decide for a level of sect I'd suppose. How
> about doing it for sect1 and sect2 elements?
Sounds good for me, I propose to include additionally 'book, part, chapter, preface,
index, appendix'. So, the list grows to:
'book, part, chapter, preface, index, appendix, sect1, sect2'
> By the way, it's valid not to have a revremark element.
Oh, that would be nice. Are you sure? I tested it and it gave me an
error, but could have been my fault. Haven't investigated more ...
> >The revremark element is left blank. I'm not sure if we should keep the
> >version history via comments and put a remark about the last
> >changes in the revision tag.
>
> So there we have the second important issue. As far as I see the usage of revhistory as
> proposed here has not the power to replace the remarks done for authoring in the head of each
> file.
I proposed to use only the last revision, because the last discussion
turned out, that most authors don't want to write the each change in a
revhistory element. I'm fine with that. Keeping the comments as a small
changelog for each article isn't that verbose as it would be, if we use
XML.
> This is because your proposal gives the reader of the manual a date which he knows then
> is the least age of the content. Additionally he gets the revision - whatever that will tell
> him.
> It's neither language specific, nor does it contain the information about what changed in the
> content of a file at a specific time.
Is this really important? It is more important for the reader IMO, that
he reads an up-to-date document and not the first draft of one article.
Therefore having a revision and a date is much more interesting than
what was changed in the last revision.
Btw. why do you want to provide language specific revision logs?
> So, whether we extend the revhistory to something like:
>
> [...] example with more than one revision elements
>
> which is pretty verbose, but can replace the comments with something
> machine readable.
Hm.. no... let us keep the comments...
Greetings,
--
Roman Joost
www: http://www.romanofski.de
email: romanofski@xxxxxxxx
Attachment:
pgpgm0IELQOzu.pgp
Description: PGP signature
_______________________________________________ Gimp-docs mailing list Gimp-docs@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs
