Appendix DG1. The CVS リポジトリ(置き場所)

Table of Contents
CVS のツリー構造
匿名(anonymous) CVS を通してソ ースを取得する
CVSup 経由でソースを取ってくる

The Postgres source code is stored and managed using the CVS code management system.

Postgres のソースコードは、 CVS コード管理システムを使って格納・ 管理されています。

At least two methods, anonymous CVS and CVSup, are available to pull the CVS code tree from the Postgres server to your local machine.

Postgres のサーバからあなた自身のマシ ンに CVS コードツリーを引っ張ってくる には、少なくとも anonymous CVS と CVSup という2つの方法があります。

CVS のツリー構造

Author: Written by Marc G. Fournier on 1998-11-05.

The command cvs checkout has a flag, -r, that lets you check out a certain revision of a module. This flag makes it easy to, for example, retrieve the sources that make up release 1.0 of the module `tc' at any time in the future:

cvs checkout には、あるモジュールの特定のリビ ジョン(版)からチェックアウトするための -r と いうフラグがあります。これにより、将来にわたっていつの時点におい ても、たとえば以下のようにモジュール 'tc' のリリース 1.0 となる ソースを取り出す、といったことができます。

$ cvs checkout -r REL6_4 tc
This is useful, for instance, if someone claims that there is a bug in that release, but you cannot find the bug in the current working copy. これにより、たとえば、誰かがその版にバグがあることを指摘してくれ たのだが、現在動いているバージョンのコピーからはそのバグを見つけ ることができない、といった場合に役立ちます。

Tip: You can also check out a module as it was at any given date using the -D option.

また -D を使うと、あるモジュールを、与えられた 日付でチェックアウトしたかのように見せることができます。

When you tag more than one file with the same tag you can think about the tag as "a curve drawn through a matrix of filename vs. revision number". Say we have 5 files with the following revisions:

1つ以上のファイルに同じタグをつけた場合でも、そのタグを「ファイ ル名と版数によるマトリックスを通して描かれたカーブ」と見なすこと ができます。たとえば、以下のような複数の版を持つ5つのファイルが あるとします:

             file1   file2   file3   file4   file5
             1.1     1.1     1.1     1.1  /--1.1*      <-*-  TAG
             1.2*-   1.2     1.2    -1.2*-
             1.3  \- 1.3*-   1.3   / 1.3
             1.4          \  1.4  /  1.4
                           \-1.5*-   1.5
then the tag "TAG" will reference file1-1.2, file2-1.3, etc. ☆動詞がないぞー そしてそのタグ "TAG" は file1-1.2, file2-1.3 を指しているとします。

Note: For creating a release branch, other then a -b option added to the command, it's the same thing. ☆なんとなく意味不明なので、ごまかしてます。

リリース用の枝を生成するには、コマンドに -b オプションを追加して やります。

So, to create the v6.4 release I did the following:

つまり、v6.4 版を作成するために、私は以下のようにしました:

$ cd pgsql
$ cvs tag -b REL6_4
which will create the tag and the branch for the RELEASE tree. これはそのタグと、リリース用のツリーのための枝を作ります。

Now, for those with CVS access, it's too simple. First, create two subdirectories, RELEASE and CURRENT, so that you don't mix up the two. Then do:

ここまでくれば、実際に CVS でアクセス するのは非常に簡単です。まず RELEASE とCURRENT という2つのサブ ディレクトリを作って、2つが混ざり合わないようにします。

cvs checkout -P -r REL6_4 pgsql
cvs checkout -P pgsql
which results in two directory trees, RELEASE/pgsql and CURRENT/pgsql. From that point on, CVS will keep track of which repository branch is in which directory tree, and will allow independent updates of either tree. この結果は RELEASE/pgsqlCURRENT/pgsql という2つのディレクトリに出力されます。 この時点から、CVS は双方のディレクト リ中にあるリポジトリの枝を監視するようになるので、双方の枝はお互 いに独立して更新できるようになります。

If you are only working on the CURRENT source tree, you just do everything as before we started tagging release branches.

CURRENT のソースツリーの方だけで作業している限りは、リリース用の枝のタグをつけ 始める前と同様うに、何をしても大丈夫です。

After you've done the initial checkout on a branch


$ cvs checkout -r REL6_4
anything you do within that directory structure is restricted to that branch. If you apply a patch to that directory structure and do a を済ませた後は、そのディレクトリ構造の内部で行ったことはすべてそ の枝の内部だけに影響するように制限されます。そのディレクトリ構造 へパッチを適用し、その中で
cvs commit
while inside of it, the patch is applied to the branch and only the branch. すれば、その枝 だけ にパッチが適用されます。