CVSのローカル使用
4100 ワード
cvsはバージョン制御ソフトウェアであり、複数の人が同じコードを共同で開発する場合、異なる開発者のソフトウェアバージョンを効率的に制御することができる.
私は個人的にコードを開発しますが、開発のバージョン管理も望んでいます.
まずCVSをインストールし、CVSディレクトリを設定し、CVSを初期化します.
新しいコードの開発も修正も可能である.
まずプロジェクトフォルダを作成し(このフォルダの内容を勝手に変更しないでください)、CVSにプロジェクトをインポートし、CVSでプロジェクトを別のフォルダにエクスポートします(このフォルダでプロジェクトを変更します)
コードを修正する場合(Aフォルダの下でBフォルダの下の内容を修正し、フォルダを勝手に移動することはできません)、まずBフォルダを別の場所(Cなど)に移動し、インポート時にBフォルダの名前をproject_とすることができますname,最後にAに項目をエクスポートする.このときCはソースコードの格納先であり,Bでコードを修正してコミットすることができる.
以下はCVSの日常使用時のコマンドです.
ファイルを最新バージョンのcvs updateに同期するにはファイル名を指定しません.cvsはすべてのサブディレクトリの下のファイルを同期します.ファイル名/ディレクトリを指定してcvs update file_を同期することもできます.nameは毎日仕事を始める前に、または自分の仕事をCVSライブラリに導入する前に一度やったほうがいいです.そして、Virvual SourceSafeとは異なり、CVSにはファイルロックの概念がありません.すべての衝突はcommitの前に解決されます.修正中に他の人がCVSライブラリに修正してcommitした場合、CVSはファイルの衝突を通知します.衝突部分を自動的に>>>>>content on cvs server<<<>>>>でマークし、衝突内容の取捨選択を確認します.バージョンの競合は通常、複数の人が1つのファイルを変更したことによるものですが、このようなプロジェクト管理上の問題はCVSによって解決されることを期待すべきではありません.
CVSライブラリに書き込みを確認cvs commit-m"write some comments here"file_name
注意:CVSの多くの動作はcvs commitで最後に確認して修正されるので、毎回1つのファイルしか修正しないほうがいいです.確認する前に、ユーザーが修正コメントを記入して、他の開発者が修正の原因を理解できるようにする必要があります.-m「comments」と書かずに`cvs commit file_を直接確認するとname`の場合、cvsはシステムのデフォルトのテキストエディタ(一般的にvi)を自動的に呼び出してコメントを書き込むように要求します.注釈の質はとても重要です:だから書かなければならないだけではなくて、その上いくつかの比較的に意義のある内容を書かなければなりません:他の開発者がよく理解できない注釈を便利にするために、他の開発者に迅速に理解させることができません:-m“bug fixed”甚だしきに至っては-m”の良い注釈、甚だしきに至っては中国語:-m“ユーザー登録の過程の中でEmailアドレスの検査に参加しました” あるバージョンの注釈を修正する:CVSライブラリに1つのファイルしか確認しないのは良い習慣ですが、ファイル名を指定するのを忘れて、複数のファイルを同じ注釈commitでCVSライブラリに注釈することがあります.以下のコマンドで、あるファイルのあるバージョンの注釈を修正することができます.cvs admin-m 1.3:「write some comments here」file_nameファイルを追加して新しいファイルを作成したら、例えばtouch new_filecvs add new_file注意:画像、Wordドキュメントなどの非純粋なテキストの項目については、cvs add-kbオプションを使用して2進数ファイルでインポートする必要があります(kは拡張オプション、bはbinaryを表します).そうしないと、cvs add-kb new_file.gifcvs add -kb readme.doc
キーワード置換属性が最初のインポート時に設定が間違っていたらどうしますか?cvs admin -kkv new_file.css 次に、cvs ci-m「write some comments here」の変更を確認し、コメントします.
削除ファイルソースファイルを物理的に削除すると、rm file_namecvs rm file_nameその後、cvs ci-m「write some comments here」の前の2ステップを修正して注釈する方法は、cvs rm-f file_namecvs ci-m「why delete file」注意:多くのcvsコマンドには略語形式があります:commit=>ci;update=>up; checkout=>co/get; remove=>rm;
ディレクトリcvs add dirの追加name変更履歴の表示cvs log file_namecvs history file_name現在のファイルの異なるバージョンの違いを表示cvs diff-r 1.3-r 1.5 file_name現在のファイルとライブラリ内の対応するファイルの違いを表示cvs diff file_namecvsのwebインタフェースは、ファイルの修正とバージョンの違いを比較するのに便利な方法を提供しています.具体的なインストール設定は、後のcvswebを参照してください.
CVSで古いバージョンを復元する方法が正しい:cvs update-r 1.2 file.nameというコマンドがfile.nameにSTICK TAG:“1.2”を追加する場合、あなたの本意は1.2バージョンの正しいリカバリバージョンに復元したいだけですが、cvs update-p-r 1.2 file_name >file_nameうっかりSTICK TAGになってしまったらcvs update-Aで解決
ファイル/ファイルの名前を変更するcvsにはcvs moveまたはcvs renameはありません.この2つの操作は、先にcvs remove old_file_name、そしてcvs add new_file_nameが実現した.
ディレクトリを削除/移動する最も便利な方法は、管理者に直接移動させ、CVSROOT内の対応するディレクトリを削除することです(CVSの1つのプロジェクトの下のサブディレクトリはすべて独立しているため、$CVSROOTディレクトリの下に移動しても新しい独立したプロジェクトとすることができます:木のように、実際には任意の枝を切っても独立して生存することができます)、ディレクトリを修正した後、開発者にプロジェクトcvs checkout projectの再エクスポートを要求するnameまたはcvs update-dPで同期します.
プロジェクトのリリースでCVSディレクトリを持たないソースファイルをエクスポートして開発したとき、各開発ディレクトリの下でCVS/ディレクトリが作成されていることに気づいたかもしれません.現在のディレクトリとCVSライブラリの対応情報を記録するファイルがあります.しかし、プロジェクトのリリース時には、ファイルディレクトリにCVS情報を含むCVSディレクトリを持たないことが一般的ですね.この使い捨てのエクスポートプロセスはcvs exportコマンドを使用しますが、exportは1つのTAGまたは日付に対してのみエクスポートできます.例えば、cvs export-r release 1 project_name cvs export -D 20021023 project_namecvs export -D now project_name
私は個人的にコードを開発しますが、開発のバージョン管理も望んでいます.
まずCVSをインストールし、CVSディレクトリを設定し、CVSを初期化します.
sudo apt-get install cvs
CVSROOT=~/cvs
cvs init新しいコードの開発も修正も可能である.
まずプロジェクトフォルダを作成し(このフォルダの内容を勝手に変更しないでください)、CVSにプロジェクトをインポートし、CVSでプロジェクトを別のフォルダにエクスポートします(このフォルダでプロジェクトを変更します)
mkdir project_dir
cvs import -m "write some comments here" project_name vendor_tag release_tag
cvs checkout project_nameコードを修正する場合(Aフォルダの下でBフォルダの下の内容を修正し、フォルダを勝手に移動することはできません)、まずBフォルダを別の場所(Cなど)に移動し、インポート時にBフォルダの名前をproject_とすることができますname,最後にAに項目をエクスポートする.このときCはソースコードの格納先であり,Bでコードを修正してコミットすることができる.
以下はCVSの日常使用時のコマンドです.
ファイルを最新バージョンのcvs updateに同期するにはファイル名を指定しません.cvsはすべてのサブディレクトリの下のファイルを同期します.ファイル名/ディレクトリを指定してcvs update file_を同期することもできます.nameは毎日仕事を始める前に、または自分の仕事をCVSライブラリに導入する前に一度やったほうがいいです.そして、Virvual SourceSafeとは異なり、CVSにはファイルロックの概念がありません.すべての衝突はcommitの前に解決されます.修正中に他の人がCVSライブラリに修正してcommitした場合、CVSはファイルの衝突を通知します.衝突部分を自動的に>>>>>content on cvs server<<<
CVSライブラリに書き込みを確認cvs commit-m"write some comments here"file_name
注意:CVSの多くの動作はcvs commitで最後に確認して修正されるので、毎回1つのファイルしか修正しないほうがいいです.確認する前に、ユーザーが修正コメントを記入して、他の開発者が修正の原因を理解できるようにする必要があります.-m「comments」と書かずに`cvs commit file_を直接確認するとname`の場合、cvsはシステムのデフォルトのテキストエディタ(一般的にvi)を自動的に呼び出してコメントを書き込むように要求します.注釈の質はとても重要です:だから書かなければならないだけではなくて、その上いくつかの比較的に意義のある内容を書かなければなりません:他の開発者がよく理解できない注釈を便利にするために、他の開発者に迅速に理解させることができません:-m“bug fixed”甚だしきに至っては-m”の良い注釈、甚だしきに至っては中国語:-m“ユーザー登録の過程の中でEmailアドレスの検査に参加しました” あるバージョンの注釈を修正する:CVSライブラリに1つのファイルしか確認しないのは良い習慣ですが、ファイル名を指定するのを忘れて、複数のファイルを同じ注釈commitでCVSライブラリに注釈することがあります.以下のコマンドで、あるファイルのあるバージョンの注釈を修正することができます.cvs admin-m 1.3:「write some comments here」file_nameファイルを追加して新しいファイルを作成したら、例えばtouch new_filecvs add new_file注意:画像、Wordドキュメントなどの非純粋なテキストの項目については、cvs add-kbオプションを使用して2進数ファイルでインポートする必要があります(kは拡張オプション、bはbinaryを表します).そうしないと、cvs add-kb new_file.gifcvs add -kb readme.doc
キーワード置換属性が最初のインポート時に設定が間違っていたらどうしますか?cvs admin -kkv new_file.css 次に、cvs ci-m「write some comments here」の変更を確認し、コメントします.
削除ファイルソースファイルを物理的に削除すると、rm file_namecvs rm file_nameその後、cvs ci-m「write some comments here」の前の2ステップを修正して注釈する方法は、cvs rm-f file_namecvs ci-m「why delete file」注意:多くのcvsコマンドには略語形式があります:commit=>ci;update=>up; checkout=>co/get; remove=>rm;
ディレクトリcvs add dirの追加name変更履歴の表示cvs log file_namecvs history file_name現在のファイルの異なるバージョンの違いを表示cvs diff-r 1.3-r 1.5 file_name現在のファイルとライブラリ内の対応するファイルの違いを表示cvs diff file_namecvsのwebインタフェースは、ファイルの修正とバージョンの違いを比較するのに便利な方法を提供しています.具体的なインストール設定は、後のcvswebを参照してください.
CVSで古いバージョンを復元する方法が正しい:cvs update-r 1.2 file.nameというコマンドがfile.nameにSTICK TAG:“1.2”を追加する場合、あなたの本意は1.2バージョンの正しいリカバリバージョンに復元したいだけですが、cvs update-p-r 1.2 file_name >file_nameうっかりSTICK TAGになってしまったらcvs update-Aで解決
ファイル/ファイルの名前を変更するcvsにはcvs moveまたはcvs renameはありません.この2つの操作は、先にcvs remove old_file_name、そしてcvs add new_file_nameが実現した.
ディレクトリを削除/移動する最も便利な方法は、管理者に直接移動させ、CVSROOT内の対応するディレクトリを削除することです(CVSの1つのプロジェクトの下のサブディレクトリはすべて独立しているため、$CVSROOTディレクトリの下に移動しても新しい独立したプロジェクトとすることができます:木のように、実際には任意の枝を切っても独立して生存することができます)、ディレクトリを修正した後、開発者にプロジェクトcvs checkout projectの再エクスポートを要求するnameまたはcvs update-dPで同期します.
プロジェクトのリリースでCVSディレクトリを持たないソースファイルをエクスポートして開発したとき、各開発ディレクトリの下でCVS/ディレクトリが作成されていることに気づいたかもしれません.現在のディレクトリとCVSライブラリの対応情報を記録するファイルがあります.しかし、プロジェクトのリリース時には、ファイルディレクトリにCVS情報を含むCVSディレクトリを持たないことが一般的ですね.この使い捨てのエクスポートプロセスはcvs exportコマンドを使用しますが、exportは1つのTAGまたは日付に対してのみエクスポートできます.例えば、cvs export-r release 1 project_name cvs export -D 20021023 project_namecvs export -D now project_name