You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ma...@apache.org on 2022/11/30 17:10:34 UTC
[tomcat] branch 9.0.x updated: Replace references to CVS with more generic language
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/9.0.x by this push:
new 538d0a9e32 Replace references to CVS with more generic language
538d0a9e32 is described below
commit 538d0a9e32f721500bee9e35e2f45851501a5e88
Author: Mark Thomas <ma...@apache.org>
AuthorDate: Wed Nov 30 17:07:12 2022 +0000
Replace references to CVS with more generic language
---
webapps/docs/appdev/installation.xml | 16 +++----
webapps/docs/appdev/processes.xml | 90 +++++++++++++++---------------------
webapps/docs/appdev/source.xml | 58 ++++++-----------------
webapps/docs/changelog.xml | 5 ++
webapps/docs/config/host.xml | 3 +-
5 files changed, 67 insertions(+), 105 deletions(-)
diff --git a/webapps/docs/appdev/installation.xml b/webapps/docs/appdev/installation.xml
index dd40ff568e..b232c1542d 100644
--- a/webapps/docs/appdev/installation.xml
+++ b/webapps/docs/appdev/installation.xml
@@ -81,19 +81,17 @@ execute the <code>ant</code> shell command directly.</p>
</subsection>
-<subsection name="CVS">
+<subsection name="Source Code Control">
<p>Besides the required tools described above, you are strongly encouraged
-to download and install a <em>source code control</em> system, such as the
-<strong>Concurrent Version System</strong> (CVS), to maintain historical
-versions of the source files that make up your web application. Besides
-the server, you will also need appropriate client
-tools to check out source code files, and check in modified versions.</p>
+to download and install a <em>source code control</em> system, such as Git,
+Subversion, CVS or one of the many alternatives. You will need appropriate
+client tools to check out source code files, and check in modified versions and,
+depending on the tool and hosting option you choose, you may need to obtain and
+install server software or sign up for an account with a cloud provider.</p>
<p>Detailed instructions for installing and using source code control
-applications is beyond the scope of this manual. However, CVS server and
-client tools for many platforms (along with documentation) can be downloaded
-from <a href="http://www.cvshome.org/">http://www.cvshome.org/</a>.</p>
+applications is beyond the scope of this manual.</p>
</subsection>
diff --git a/webapps/docs/appdev/processes.xml b/webapps/docs/appdev/processes.xml
index 9ee5112554..758db1b235 100644
--- a/webapps/docs/appdev/processes.xml
+++ b/webapps/docs/appdev/processes.xml
@@ -43,11 +43,10 @@ multiple programmers involved, as long as you have an appropriate source code
control system and internal team rules about who is working on what parts
of the application at any given time.</p>
-<p>The task descriptions below assume that you will be using CVS for source
-code control, and that you have already configured access to the appropriate
-CVS repository. Instructions for doing this are beyond the scope of this
-manual. If you are using a different source code control environment, you
-will need to figure out the corresponding commands for your system.</p>
+<p>The task descriptions below do not assume any particular source code control
+system but simply identify when and what source code control tasks are typically
+performed. You will need to idenitfy the appropriate source code control
+commands for your system.</p>
<subsection name="One-Time Setup of Ant and Tomcat for Development">
@@ -83,10 +82,8 @@ be using. The directory structure is described in <a href="source.html">the
previous section</a>, or you can use the
<a href="sample/">sample application</a> as a starting point.</p>
-<p>Create your project source directory, and define it within your CVS
-repository. This might be done by a series of commands like this, where
-<code>{project}</code> is the name under which your project should be
-stored in the CVS repository, and {username} is your login username:</p>
+<p>Create your project source directory, and define it within your source code
+control system. This might be done by a series of commands like this:</p>
<source><![CDATA[cd {my home directory}
mkdir myapp <-- Assumed "project source directory"
cd myapp
@@ -94,14 +91,12 @@ mkdir docs
mkdir src
mkdir web
mkdir web/WEB-INF
-cvs import -m "Initial Project Creation" {project} \
- {username} start]]></source>
+cvs or svn or git ... <-- Add this structure to the appropriate repository
+]]></source>
-<p>Now, to verify that it was created correctly in CVS, we will perform a
-checkout of the new project:</p>
-<source><![CDATA[cd ..
-mv myapp myapp.bu
-cvs checkout {project}]]></source>
+<p>To verify that the project was created correctly in the source code control
+repository, you may wish to check out the project to a separate directory and
+confirm that all the expected contents are present.</p>
<p>Next, you will need to create and check in an initial version of the
<code>build.xml</code> script to be used for development. For getting
@@ -111,12 +106,8 @@ or code it from scratch.</p>
<source><![CDATA[cd {my home directory}
cd myapp
emacs build.xml <-- if you want a real editor :-)
-cvs add build.xml
-cvs commit]]></source>
-
-<p>Until you perform the CVS commit, your changes are local to your own
-development directory. Committing makes those changes visible to other
-developers on your team that are sharing the same CVS repository.</p>
+cvs or svn or git ... <-- Add this file to the repository
+]]></source>
<p>The next step is to customize the Ant <em>properties</em> that are
named in the <code>build.xml</code> script. This is done by creating a
@@ -137,8 +128,8 @@ manager.username=myusername
manager.password=mypassword</source>
<p>In general, you will <strong>not</strong> want to check the
-<code>build.properties</code> file in to the CVS repository, because it
-is unique to each developer's environment.</p>
+<code>build.properties</code> file in to the source code control repository,
+because it is unique to each developer's environment.</p>
<p>Now, create the initial version of the web application deployment
descriptor. You can base <code>web.xml</code> on the
@@ -146,8 +137,8 @@ descriptor. You can base <code>web.xml</code> on the
<source><![CDATA[cd {my home directory}
cd myapp/web/WEB-INF
emacs web.xml
-cvs add web.xml
-cvs commit]]></source>
+cvs or svn or git ... <-- Add this file to the repository
+]]></source>
Note that this is only an example web.xml file. The full definition
of the deployment descriptor file is in the
@@ -164,35 +155,30 @@ As described in <a href="source.html">Source Organization</a>, newly created
source files should be located in the appropriate subdirectory, under your
project source directory.</p>
-<p>Whenever you wish to refresh your development directory to reflect the
-work performed by other developers, you will ask CVS to do it for you:</p>
-<source><![CDATA[cd {my home directory}
-cd myapp
-cvs update -dP]]></source>
+<p>You should regularly refresh your development directory to reflect the
+work performed by other developers.</p>
-<p>To create a new file, go to the appropriate directory, create the file,
-and register it with CVS. When you are satisfied with it's contents (after
-building and testing is successful), commit the new file to the repository.
-For example, to create a new JSP page:</p>
+<p>To create a new file, go to the appropriate directory and create the file.
+When you are satisfied with its contents (after building and testing is
+successful), add the new file to the repository. For example, to create a new
+JSP page:</p>
<source><![CDATA[cd {my home directory}
cd myapp/web <-- Ultimate destination is document root
emacs mypage.jsp
-cvs add mypage.jsp
... build and test the application ...
-cvs commit]]></source>
+cvs or svn or git ... <-- Add this file to the repository
+]]></source>
-<p>Java source code that is defined in packages must be organized in a
-directory hierarchy (under the <strong>src/</strong> subdirectory) that
-matches the package names. For example, a Java class named
+<p>Java source code that is defined in packages must be organized in a directory
+hierarchy (under the <strong>src/</strong> subdirectory) that matches the
+package names. For example, a Java class named
<code>com.mycompany.mypackage.MyClass.java</code> should be stored in file
<code>src/com/mycompany/mypackage/MyClass.java</code>.
-Whenever you create a new subdirectory, don't forget to
-register it with CVS.</p>
+Whenever you create a new file, don't forget to add it to the source code
+control system.</p>
<p>To edit an existing source file, you will generally just start editing
-and testing, then commit the changed file when everything works. Although
-CVS can be configured to required you to "check out" or "lock" a file you
-are going to be modifying, this is generally not used.</p>
+and testing, then commit the changed file when everything works.</p>
</subsection>
@@ -249,9 +235,9 @@ a pattern like this:</p>
<li><p><em>Modify and rebuild as needed</em>. As you discover that changes
are required, make those changes in the original <strong>source</strong>
files, not in the output build directory, and re-issue the
- <code>ant compile</code> command. This ensures that your changes will
- be available to be saved (via <code>cvs commit</code>) later on --
- the output build directory is deleted and recreated as necessary.
+ <code>ant compile</code> command. This ensures that your changes will be
+ available to be saved (via your chosen source code control system) later on
+ -- the output build directory is deleted and recreated as necessary.
</p></li>
<li><p><em>Reload the application</em>. Tomcat will recognize changes in
JSP pages automatically, but it will continue to use the old versions
@@ -280,10 +266,10 @@ following general steps are required:</p>
<li><p>Issue the command <code>ant all</code> from the project source
directory, to rebuild everything from scratch one last time.
</p></li>
-<li><p>Use the <code>cvs tag</code> command to create an identifier for
- all of the source files utilized to create this release. This allows
- you to reliably reconstruct a release (from sources) at a later
- time.
+<li><p>Use the source code control system to tag the current state of the code
+ to create an identifier for all of the source files utilized to create this
+ release. This allows you to reliably reconstruct a release (from sources)
+ at a later time.
</p></li>
<li><p>Issue the command <code>ant dist</code> to create a distributable
web application archive (WAR) file, as well as a JAR file containing
diff --git a/webapps/docs/appdev/source.xml b/webapps/docs/appdev/source.xml
index 5ccdf3b127..016cdddd16 100644
--- a/webapps/docs/appdev/source.xml
+++ b/webapps/docs/appdev/source.xml
@@ -167,57 +167,29 @@ build is performed.</p>
<p>As mentioned earlier, it is highly recommended that you place all of the
source files that comprise your application under the management of a
-source code control system like the Concurrent Version System (CVS). If you
-elect to do this, every directory and file in the source hierarchy should be
-registered and saved -- but none of the generated files. If you register
-binary format files (such as images or JAR libraries), be sure to indicate
-this to your source code control system.</p>
+source code control system. If you elect to do this, every directory and file
+in the source hierarchy should be registered and saved -- but none of the
+generated files. If you register binary format files (such as images or JAR
+libraries), be sure to indicate this to your source code control system.</p>
<p>We recommended (in the previous section) that you should not store the
contents of the <code>build/</code> and <code>dist/</code> directories
-created by your development process in the source code control system. An
-easy way to tell CVS to ignore these directories is to create a file named
-<code>.cvsignore</code> (note the leading period) in your top-level source
-directory, with the following contents:</p>
-<source>build
-dist
-build.properties</source>
+created by your development process in the source code control system. Source
+code control systems typically provide mechanisms to ignore these directories
+(Git uses a <code>.gitignore</code> file, Subversion uses the
+<code>svn:ignore</code> property, CVS uses a <code>.cvsignore</code> file, etc.)
+You should configure your source code control system to ignore:</p>
+<ul>
+ <li>build</li>
+ <li>dist</li>
+ <li>build.properties</li>
+</ul>
<p>The reason for mentioning <code>build.properties</code> here will be
explained in the <a href="processes.html">Processes</a> section.</p>
<p>Detailed instructions for your source code control environment are beyond
-the scope of this manual. However, the following steps are followed when
-using a command-line CVS client:</p>
-<ul>
-<li>To refresh the state of your source code to that stored in the
- the source repository, go to your project source directory, and
- execute <code>cvs update -dP</code>.
- <br/><br/></li>
-<li>When you create a new subdirectory in the source code hierarchy, register
- it in CVS with a command like <code>cvs add {subdirname}</code>.
- <br/><br/></li>
-<li>When you first create a new source code file, navigate to the directory
- that contains it, and register the new file with a command like
- <code>cvs add {filename}</code>.
- <br/><br/></li>
-<li>If you no longer need a particular source code file, navigate to the
- containing directory and remove the file. Then, deregister it in CVS
- with a command like <code>cvs remove {filename}</code>.
- <br/><br/></li>
-<li>While you are creating, modifying, and deleting source files, changes
- are not yet reflected in the server repository. To save your changes in
- their current state, go to the project source directory
- and execute <code>cvs commit</code>. You will be asked to write a brief
- description of the changes you have just completed, which will be stored
- with the new version of any updated source file.</li>
-</ul>
-
-<p>CVS, like other source code control systems, has many additional features
-(such as the ability to tag the files that made up a particular release, and
-support for multiple development branches that can later be merged). See the
-links and references in the <a href="introduction.html">Introduction</a> for
-more information.</p>
+the scope of this manual.</p>
</section>
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index bb212424cb..e8052c50ed 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -142,6 +142,11 @@
<bug>66348</bug>: Update the JARs listed in the class loader
documentation and note which ones are optional. (markt)
</fix>
+ <fix>
+ Documentation. Replace references in the application developer's guide
+ to CVS with more general references to a source code control system.
+ (markt)
+ </fix>
</changelog>
</subsection>
<subsection name="Other">
diff --git a/webapps/docs/config/host.xml b/webapps/docs/config/host.xml
index 45c2d76124..3cb34adc32 100644
--- a/webapps/docs/config/host.xml
+++ b/webapps/docs/config/host.xml
@@ -156,7 +156,8 @@
<p>A regular expression defining paths to ignore when
<code>autoDeploy</code> and <code>deployOnStartup</code> are set. This
allows you to keep your configuration in a version control system, for
- example, and not deploy a .svn or CVS folder that happens to be in the
+ example, and not deploy a <code>.svn</code>, <code>.git</code> or other
+ configuration control system folder that happens to be in the
<code>appBase</code>.</p>
<p>This regular expression is relative to <code>appBase</code>. It is
also <em>anchored</em>, meaning the match is performed against the
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org