[kde-doc-english] [cervisia] doc: Remove extra dots after entity &etc;

Burkhard Lück lueck at hube-lueck.de
Thu Apr 25 19:39:20 UTC 2013


Git commit 4320811a73f32f1866b0448349a6840d1b5d6cc6 by Burkhard Lück.
Committed on 25/04/2013 at 21:39.
Pushed by lueck into branch 'master'.

Remove extra dots after entity &etc;

M  +5    -5    doc/index.docbook

http://commits.kde.org/cervisia/4320811a73f32f1866b0448349a6840d1b5d6cc6

diff --git a/doc/index.docbook b/doc/index.docbook
index 5451594..89f735c 100644
--- a/doc/index.docbook
+++ b/doc/index.docbook
@@ -91,7 +91,7 @@ project (commercial or not), but you can take advantage of the nice revision
 control features offered by &CVS; even for a project developed exclusively by
 you. It is easy to set up a local repository, and you will gain the ability to
 track changes that caused bugs, revert changes, avoid accidental loss of
-information, &etc;.
+information, &etc;
 </para>
 
 <para>
@@ -124,7 +124,7 @@ If you plan to develop a complex project, it is a good idea to use the
 &CVS; features, even if you are the only developer. You can make all changes in
 the working copy, and use &cervisia; (or any other &CVS; tool) to update and
 commit. This way, you will gain the ability to track changes that caused bugs,
-revert changes, avoid accidental loss of information, &etc;. Using &cervisia;, it
+revert changes, avoid accidental loss of information, &etc; Using &cervisia;, it
 is simple to create a local repository.
 </para>
 
@@ -182,7 +182,7 @@ Repositories dialog</phrase></textobject>
 <para>
 There are several methods to access a &CVS; repository. It may be reached via
 password authentication (:pserver:), secure shell (using :ext:), local
-repository (:local:), &etc;. The format for the repository location is
+repository (:local:), &etc; The format for the repository location is
 (optional items appear between square brackets):
 </para>
 
@@ -588,9 +588,9 @@ Tags are used to mark a version of a project. &CVS; stamps one
 version of each file with the tag, so when you checkout or
 update to a specific tag, you will get always the same file versions.
 Therefore, in opposition to branches, tags are not dynamic: you cannot develop a
-tag. Tags are useful to mark releases, big changes in the code, &etc;.
+tag. Tags are useful to mark releases, big changes in the code, &etc;
 Using tags, you can easily return the project to a previous state, to reproduce and
-track bugs, generate the release code again, &etc;.
+track bugs, generate the release code again, &etc;
 </para>
 
 <figure id="screenshot-checkout" float="1">


More information about the kde-doc-english mailing list