commit 54f0c80e085e462a5a5649fccb425f48eae36a81
parent 45307d65bebda4c274955d9f2939ddc04dac00e7
Author: Jake Bauer <jbauer@paritybit.ca>
Date: Wed, 3 May 2023 21:22:16 -0400
*
Diffstat:
| M | content/garden/cvs.md | | | 105 | ++++++++++++++++++++++++++++++++++++++++++++++++++----------------------------- |
1 file changed, 67 insertions(+), 38 deletions(-)
diff --git a/content/garden/cvs.md b/content/garden/cvs.md
@@ -6,50 +6,63 @@ Summary: CVS
CVS is the Concurrent Versions System. It is a source control/version
control/revision control system like Git, Mercurial, Fossil, SVN, etc.
-I've written this document both as a reference for myself and as a quick
-start guide that can hopefully be useful to others wanting to learn CVS.
-Since git is a similar program that many likely already know, I've
-written this with comparisons to git's functionality and with the
-assumption that the reader is already familiar with revision control
-systems.
+CVS has a pure client-server model. Unlike git's distributed model, with
+CVS you work directly with the remote repository for doing things like
+committing, getting different revisions of files, comparing different
+revisions, and so on. You aren't ever synchronising the state of your
+repository with a remote repository the same way you do with git.
-For actual documentation, check out the cvs(1) manpage and the
-[CVS
-book](https://durak.org/sean/pubs/software/cvsbook/index.html#Top).
+## Table of Contents
<ul>
<li><a href="#terminology">Terminology</a></li>
<li><a href="#checking-out-source-code">Checking Out Source Code</a></li>
+ <ul>
+ <li><a href="#local-repositories">Local Repositories</a></li>
+ </ul>
<li><a href="#committing-changes">Committing Changes</a></li>
<li><a href="#adding-a-new-file-or-directory">Adding a New File or Directory</a></li>
<li><a href="#removing-a-file-or-directory">Removing a File or Directory</a></li>
<li><a href="#renaming-a-file-or-directory">Renaming a File or Directory</a></li>
<li><a href="#updating-your-working-directory">Updating Your Working Directory</a></li>
- <li><a href="#resolving-merge-conflicts">Resolving Merge Conflicts</a></li>
+ <ul>
+ <li><a href="#resolving-merge-conflicts">Resolving Merge Conflicts</a></li>
+ </ul>
<li><a href="#comparing-file-revisions">Comparing File Revisions</a></li>
<li><a href="#reverting-changes">Reverting Changes</a></li>
<li><a href="#creating-tags">Creating Tags</a></li>
<li><a href="#the-.cvsrc-file">The ~/.cvsrc File</a></li>
</ul>
+I've written this document both as a reference for myself and as a quick
+start guide that can hopefully be useful to others wanting to learn CVS.
+Since git is a similar program that many likely already know, I've
+written this with comparisons to git's functionality and with the
+assumption that the reader is already familiar with revision control
+systems.
+
+For actual documentation, check out the cvs(1) manpage and the
+[CVS
+book](https://durak.org/sean/pubs/software/cvsbook/index.html#Top).
+
## Terminology
-CVS works entirely with a client-server model.
+A <b>module</b> is a single project (i.e. a collection of related
+files).
-A <b>module</b> is a single project (i.e. a collection of
-related files).
+A <b>repository</b> is a collection of modules. Though sometimes this
+term is used to refer to a module/project as well. A repository can live
+on a remote machine or locally on your system.
-A <b>repository</b> is where a CVS server stores the modules it
-manages. Though sometimes this term is used to refer to
-a module/project as well.
+A <b>CVS server</b> is simply a machine that has a CVS repository that
+allows people to check out code, commit changes, and so on.
You <b>check out</b> a particular module to create a copy of it
on your system, called a <b>working copy</b>.
-When you <b>commit</b> a change, the change gets immediately
-reflected in the module stored in the CVS repository. There is
-no concept of making a local commit, then pushing that commit to
-a remote repository.
+When you <b>commit</b> a change, the change gets immediately reflected
+in the CVS repository. There is no concept of making a local commit,
+then pushing that commit to a remote repository.
You <b>update</b> your local copy of the source code to bring
down and merge changes in the repository with your local working
@@ -60,50 +73,66 @@ commits that you don't have).
If you're coming from git, a "module" (sometimes also called
a repository or project) is equivalent to a git repository,
-a "repository" is equivalent to something like GitHub or
-a collection of git repositories, "checking out" is like
-cloning, "committing" is mostly the same, and "updating" is like
-pulling.
+a "repository" is equivalent to something like GitHub or a collection of
+git repositories, "checking out" is like cloning, "committing" is mostly
+the same, and "updating" is like pulling. It's a bit more complicated
+than that, but this is a decent starting point.
+
+Also, CVS stores its data in a `CVS/` directory in each directory in
+a given module whereas git stores its information in the `.git/`
+directory at the top of a git repository.
## Checking Out Source Code
-Create a local working directory `<dir>` of a remote repository:
+Assuming you're working with a repository that already exists, you can
+create a local working copy of a module in a repository like so:
```
cvs -d <remote>:<path_to_cvs_repository> checkout <module>
```
+This will create the directory `<module>` in your current working
+directory which contains a working copy of the source code.
+
For example, to check out a copy of the OpenBSD source:
```
cvs -d anoncvs@anoncvs.nl.openbsd.org:/cvs checkout -P src
```
-In this case, the `-P` option will mean that if a directory is
-empty in the remote repository, it will be pruned (removed) from
-your local working copy. You may or may not want this.
+The `-d` option specifies the `CVSROOT`, i.e. the root of the CVS
+repository. This is necessary for commands that aren't already working
+on working copy of a project (working copies remember their
+repositories).
+
+The `-P` option will mean that if a directory is empty in the remote
+repository, it will be pruned (removed) from your local working copy.
+You may or may not want this.
The `-D` flag can also be used to check out a repository as it was at
a specific date and time. For example, this will check out a module as
it was at exactly 17:00 UTC on 2023-04-30:
```
-cvs checkout -D "2023-04-30 17:00 UTC"
+cvs -d <CVSROOT> checkout -D "2023-04-30 17:00 UTC" src
```
This flag is also available for the `update`, `diff`, and other
commands.
-You can also have a CVS "server" that simply runs on your local
-machine. For example, if you create a `/var/cvs` directory then
-run `cvs init` inside of that directory, you will create a CVS
-repository. You can then `cvs import` sources to create
-a module, or simply `mkdir` a directory. Both must be followed
-by `cvs checkout` commands to create working copies of the
-module.
+### Local Repositories
+
+Although many use CVS with a remote repository which allows many people
+to access and work on the code stored there; you can also create
+a repository that simply exists on your local machine and work with
+that. Creating a local repository is as simple as making a directory for
+it (e.g. `/var/cvs`), then running `cvs -d <dir> init`. You can then
+`cvs import` sources to create a module, or simply `mkdir` a directory
+in the CVSROOT. Both must be followed by `cvs checkout` commands to
+create working copies of the module.
```
-# mkdir /var/cvs # Set permissions/ownership of this directory as required
+# mkdir /var/cvs # chown/chmod this directory as required
$ cvs -d /var/cvs init
$ cd myproject
$ cvs -d /var/cvs import myproject vendor_tag release_tag
@@ -111,7 +140,7 @@ $ cd ..
$ cvs -d /var/cvs checkout myproject
```
-Or, for an empty module, you can just
+Or, for an empty module, you can just:
```
$ mkdir /var/cvs/myproject
