Merge lp:~patrick-regan/bzr/RCStoVCS into lp:bzr

[Patrick Regan]

[Patrick Regan (patrick-regan)]

bug 490211 was raised by M. Pool, but originally brought to the attention of the bzr team by B. Finney.

Since there were some issues involving the Contributor Agreement, Mr Finney's fix could not be included (unfortunately). I have volunteered to redo the work for him.

Comments and suggestions welcome.

I'm sure the following statement is unnecessary, but in the case of some sort of legal problem I'm going to say it anyway.

I, Patrick M. Regan, have made the changes proposed without the work of Mr. Ben Finney. Although the outcome of the edits made may be similar or identical, they were not derived from Mr. Finney's work. All edits were done from scratch.

[John A Meinel (jameinel)]

review: Approve

[Ian Clatworthy (ian-clatworthy)]

review: Approve

=== modified file 'doc/developers/container-format.txt'
--- doc/developers/container-format.txt	2009-02-22 16:54:02 +0000
+++ doc/developers/container-format.txt	2009-12-02 19:15:23 +0000
@@ -129,7 +129,7 @@
 ------------------
 
 There is a requirement that each object can be given an arbitrary name.
-Some revision control systems address all content by the SHA-1 digest of
+Some version control systems address all content by the SHA-1 digest of
 that content, but this scheme is unsatisfactory for Bazaar's revision
 objects.  We can still allow addressing by SHA-1 digest for those content
 types where it makes sense.

=== modified file 'doc/en/tutorials/centralized_workflow.txt'
--- doc/en/tutorials/centralized_workflow.txt	2009-11-03 18:01:09 +0000
+++ doc/en/tutorials/centralized_workflow.txt	2009-12-02 19:15:23 +0000
@@ -294,7 +294,7 @@
 -----------------
 
 Bazaar_ has the concept of a "Shared Repository". This is similar to
-the traditional concept of a repository in other RCSs like CVS and
+the traditional concept of a repository in other VCSs like CVS and
 Subversion. For example, in Subversion you have a remote repository,
 which is where all of the history is stored, and locally you don't
 have any history information, only a checkout of the working tree

=== modified file 'doc/en/tutorials/tutorial.txt'
--- doc/en/tutorials/tutorial.txt	2009-11-19 23:30:19 +0000
+++ doc/en/tutorials/tutorial.txt	2009-12-02 19:15:23 +0000
@@ -15,14 +15,14 @@
 Introduction
 ============
 
-If you are already familiar with decentralized revision control, then
+If you are already familiar with decentralized version control, then
 please feel free to skip ahead to "Introducing Yourself to Bazaar". If,
-on the other hand, you are familiar with revision control but not
-decentralized revision control, then please start at "How DRCS is
+on the other hand, you are familiar with version control but not
+decentralized version control, then please start at "How DVCS is
 different." Otherwise, get some coffee or tea, get comfortable and get
 ready to catch up. 
 
-The purpose of revision control
+The purpose of version control
 ===============================
 
 Odds are that you have worked on some sort of textual data -- the sources
@@ -34,7 +34,7 @@
 important information that you would desperately like to get back. If this
 has ever happened to you, then you are probably ready for Bazaar.
 
-Revision control systems (which I'll henceforth call RCS) such as
+Version control systems (which I'll henceforth call VCS) such as
 Bazaar give you the ability to track changes for a directory by turning
 it into something slightly more complicated than a directory that we call
 a **branch**. The branch not only stores how the directory looks right
@@ -42,7 +42,7 @@
 do something you wish you hadn't, you can restore the directory to the way
 it looked at some point in the past.
 
-Revision control systems give users the ability to save changes to a
+Version control systems give users the ability to save changes to a
 branch by "committing a **revision**". The revision created is essentially
 a summary of the changes that were made since the last time the tree was
 saved. 
@@ -55,23 +55,23 @@
 We keep these logs so that if later there is some sort of problem with
 sftp, we can figure out when the problem probably happened. 
 
-How DRCS is different
+How DVCS is different
 =====================
 
-Many Revision Control Systems (RCS) are stored on servers. If one wants to
-work on the code stored within an RCS, then one needs to connect to the
+Many Version Control Systems (VCS) are stored on servers. If one wants to
+work on the code stored within a VCS, then one needs to connect to the
 server and "checkout" the code. Doing so gives one a directory in which a
-person can make changes and then commit. The RCS client then connects to
-the RCS server and stores the changes. This method is known as the
+person can make changes and then commit. The VCS client then connects to
+the VCS server and stores the changes. This method is known as the
 centralized model. 
 
-The centralized model can have some drawbacks. A centralized RCS requires
+The centralized model can have some drawbacks. A centralized VCS requires
 that one is able to connect to the server whenever one wants to do version
 control work. This can be a bit of a problem if your server is on some other
 machine on the internet and you are not. Or, worse yet, you **are** on the
 internet but the server is missing!
 
-Decentralized Revision Control Systems (which I'll call DRCS after this
+Decentralized Version Control Systems (which I'll call DVCS after this
 point) deal with this problem by keeping branches on the same machine as
 the client. In Bazaar's case, the branch is kept in the same place as
 the code that is being version controlled. This allows the user to save
@@ -87,7 +87,7 @@
 as Bazaar. These tools automate the process of storing data by creating
 a **revision** of the directory tree whenever the user asks. 
 
-Revision control software such as Bazaar can do much more than just
+Version control software such as Bazaar can do much more than just
 storage and performing undo.  For example, with Bazaar a developer can
 take the modifications in one branch of software and apply them to a
 related branch -- even if those changes exist in a branch owned by