summaryrefslogtreecommitdiff
path: root/Master/texmf-dist/doc/latex/vhistory/en_introduction.tex
diff options
context:
space:
mode:
authorKarl Berry <karl@freefriends.org>2013-01-23 23:53:17 +0000
committerKarl Berry <karl@freefriends.org>2013-01-23 23:53:17 +0000
commit943d3f44319a81bca1245e19f0e0e894cf404a87 (patch)
treebfb103f098d6ad816bdcfca7075f19ef5a267e10 /Master/texmf-dist/doc/latex/vhistory/en_introduction.tex
parenta0e35f2bf6cf222f13ceb9b0553d3539ab22bb7d (diff)
vhistory 1.6 (22jan13)
git-svn-id: svn://tug.org/texlive/trunk@28914 c570f23f-e606-0410-a88d-b1316a301751
Diffstat (limited to 'Master/texmf-dist/doc/latex/vhistory/en_introduction.tex')
-rw-r--r--Master/texmf-dist/doc/latex/vhistory/en_introduction.tex16
1 files changed, 8 insertions, 8 deletions
diff --git a/Master/texmf-dist/doc/latex/vhistory/en_introduction.tex b/Master/texmf-dist/doc/latex/vhistory/en_introduction.tex
index 18848537d30..9e76493ec20 100644
--- a/Master/texmf-dist/doc/latex/vhistory/en_introduction.tex
+++ b/Master/texmf-dist/doc/latex/vhistory/en_introduction.tex
@@ -2,7 +2,7 @@
It's clear to me that nobody reads introductions. Nevertheless I recommend not to skip this section, as it tries to explain, why I developed the packages sets and vhistory.
By reading the following you can see, if these packages meet your requirements.
-During software projects (hopefully) a lot of documents like specification or design are created. These are normally revised several times. To reconstruct changes, documents should contain a so called \emph{history of versions} aka change log. This is a table, whose entries contain the following data:
+During software projects (hopefully) a lot of documents like specification or design are created. These are normally revised several times. To reconstruct changes, documents should contain a so called \emph{revision history} aka change log. This is a table, whose entries contain the following data:
\begin{itemize}
\item a version number,
\item the date of the change,
@@ -11,18 +11,18 @@ During software projects (hopefully) a lot of documents like specification or de
\item a summary of the changes.
\end{itemize}
-Certain data of the history of versions shall often be repeated at other parts of the document. Typically the title-page shall quote the most recent version number and all authors of the document. The version number should although be repeated on every page, e.\,g. in a footer. By doing this, it is easy to verify, if a page is part of the most recent version or if it is outdated.
+Certain data of the revision history shall often be repeated at other parts of the document. Typically the title-page shall quote the most recent version number and all authors of the document. The version number should although be repeated on every page, e.\,g. in a footer. By doing this, it is easy to verify, if a page is part of the most recent version or if it is outdated.
-Normally the data, that is placed on say the title-page, is not (automatically) taken from the history of versions, but stated at an other part of the document. The entries in the history of versions are normally always updated. Due to stress and rush updating the data on the title-page is often forgotten. This results in inconsistent documents.
+Normally the data, that is placed on say the title-page, is not (automatically) taken from the revision history, but stated at an other part of the document. The entries in the revision history are normally always updated. Due to stress and rush updating the data on the title-page is often forgotten. This results in inconsistent documents.
From my own experience I know, that the list of authors is practically never correct, especially when several people edited a document in the course of time.
-Therefore it would be nice, if the author of a document only had to take care of the history of versions. The informations on title-page and in footers should be generated from the history of versions automatically.
+Therefore it would be nice, if the author of a document only had to take care of the revision history. The informations on title-page and in footers should be generated from the revision history automatically.
-These requirements cannot be implemented without any effort, because the titlepage for instance is processed by \LaTeX\ before the history of versions is even read.
+These requirements cannot be implemented without any effort, because the titlepage for instance is processed by \LaTeX\ before the revision history is even read.
All relevant data therefore has to be written to a file and read again before processing the titlepage. As for some applications even the moment when the aux-file is read is too late, an own file with the extension hst is created.
-The table containing the history of versions needs an own file, too, but this topic will be discussed later.
+The table containing the revision history needs an own file, too, but this topic will be discussed later.
-Another problem is the list of authors. This list cannot be created be simply concatenating the author entries, because this would result in duplicate entries. At this time the package sets was born allowing to manage simple sets of text. At every entry in the history of versions, the set of authors is merged with the set of authors given at this entry. The alphabetically sorted set of authors can then be printed wherever one likes---normally on the tile-page.
+Another problem is the list of authors. This list cannot be created be simply concatenating the author entries, because this would result in duplicate entries. At this time the package sets was born allowing to manage simple sets of text. At every entry in the revision history, the set of authors is merged with the set of authors given at this entry. The alphabetically sorted set of authors can then be printed wherever one likes---normally on the tile-page.
-The following to sections describe the two packages in more detail and explain, how to use them. I decided not to repeat anything of source code here. Those who are interested can take a look at the sources. I tried to structure and comment the sources in a way that makes it readable for humans. \ No newline at end of file
+The following to sections describe the two packages in more detail and explain, how to use them. I decided not to repeat anything of source code here. Those who are interested can take a look at the sources. I tried to structure and comment the sources in a way that makes it readable for humans.