diff --git a/plugins/cvs/DESIGN.txt b/plugins/cvs/DESIGN.txt
index 7e4db639e3..7d7770d955 100644
--- a/plugins/cvs/DESIGN.txt
+++ b/plugins/cvs/DESIGN.txt
@@ -1,59 +1,59 @@
 CVS plugin for KDevelop4
 ========================
 (C) Robert Gruber [rgruber A users!sourceforge!net]
 
 
 The CVS plugin is separated into three part.
 
 1) The CvsPart (cvspart.h)
    It is the main entry point to the CVS plugin. By implementing 
    the IVersionControl interface it offers a lot of slots that will
    invoke the different CVS actions.
    This class serves as a dispatcher. It takes the urls and options 
    for the requested CVS action and passes them to the CvsProxy (#2)
-   to get a CvsJob returned. After starting, the job's result() singal
+   to get a CvsJob returned. After starting, the job's result() signal
    gets connected either directly to CvsMainView (#3) or to a custom
    output view.
 
 2) CvsProxy (cvsproxy.h) and CvsJob (cvsjob.h)
    The CvsProxy serves as a single point of entry for creating the
    CvsJobs. The proxy offers a list of methods for the different
    supported CVS actions. Each of these methods will return a CvsJob
    object. So the caller does not have to worry about the whole 
    job and commandline creation. Calling the appropriate method will
    do all the work and return a CvsJob object ready for starting.
 
 3) The CvsMainView (cvsmainview.h) and custom view (like editorsview.h)
    The CvsMainView displays output from finished jobs. It holds a 
    KTabWidget to which everbody can add custom output views. For
    instance when the user requested a "cvs log" action, a new view
    will be added. This view will then parse the output of the "cvs log"
    job and display it in a nice way.
    But it does not make sense to add new views for every cvs action.
    For example, adding a new view everytime "cvs commit", "cvs edit" or
    similar actions get executed would be an overkill. Therefore 
    CvsMainView also provides a generic output view that just displays 
    the plain text output from such jobs. Unlike custom views, this 
    generic view can not be closed and it will simply append the ouput 
    from each job that got connected to it.
 
 
 
 The workflow of the CVS plugin looks like this:
 1) The user requests a CVS action
 2) The matching slot from CvsPart will be called
 3) Optional: The user may be prompted for additional input
    [ see: CvsPart::commit() ]
 4) CvsPart passes all needed options to the CvsProxy by calling
    it's method for the requested action.
 5) CvsProxy assembles the commandline, creates a CvsJob object and
    returns a pointer to the CvsJobs object
 6) CvsPart calls start() for the returned CvsJob object and continues
    with either #6.1 or #6.2
 6.1) Connectes the job's result() signal to the generic ouput view 
      from CvsMainView
 6.2) Creates a custom view, connects the job's result() signal to it
      and adds the view to CvsMainView