約 289,893 件
https://w.atwiki.jp/sevenlives/pages/635.html
CVSクライアント?ワークディレクトリ(CVS)? チェックアウト(CVS)? コミット(CVS)? アップデート(CVS)? リリース(CVS)?
https://w.atwiki.jp/hecmw/pages/24.html
FrontSTR開発用CVSマニュアル 本ページはFrontSTR開発者用にCVSの利用方法の概要を説明するページです。 CVSの使い方などはRISTの当時と基本的に同じです。 当時のマニュアルをお持ちの方は参照してみてください。 作業の流れ 初期設定 プロジェクトの取得 ファイルの更新 ファイルの同期 ファイルの追加 ファイルの削除 以下、順に説明していきます。なお、以下の説明は江連、坂根両氏作成の CVSサーバ簡易メモの内容と同様です(パクリ)。 初期設定 CVSのプロジェクトが登録されているディレクトリを設定します。 #必ずしも設定している必要はありませんが、してあったほうが #何かと便利です csh系の場合 setenv CVSROOT /home/cvs bash系の場合 export CVSROOT=/home/cvs .cshrcや.bashrcに書いておくと良いでしょう。 プロジェクトの取得 プロジェクトの取得はcvs checkoutで行います。checkoutの書式は以下です。 cvs checkout (-d ディレクトリ名) プロジェクト名 skyraiders以外のマシンで利用する場合は cvs -d ext ユーザー名@skyraiders.iis.u-tokyo.ac.jp /home/cvs checkout FrontSTR ディレクトリ名を省略した場合、カレントディレクトリにプロジェクトファイルが作成されます。 たとえば、ホームのwork以下にプロジェクトを取得したい場合は以下のようにします。 cvs checkout -d ~/work FrontSTR 初期設定でCVSROOTを設定していない場合は cvs /home/cvs checkout -d ~/work FrontSTR なお,取得したプロジェクトのファイルの改変をしない場合にはcvs exportを使います. exportはcheckoutと違って,CVSの管理下に置かない状態でプロジェクトを取りだすことができます. 要は,checkoutではプロジェクトの各ディレクトリの下にCVSというディレクトリができますが,exportではこのディレクトリができません. 但し,CVSの管理下に置かれませんので,cvs updateで最新ソースコードにアップデートすることはできません. 例えば,CVSサーバから最新のソースコードを取得したい場合には,以下のようにします. cvs -d ext ユーザー名@skyraiders.iis.u-tokyo.ac.jp /home/cvs export -D tomorrow FrontSTR cvs exportは,-Dによる日付指定が必須です. 最新の内容を取得するのであれば-D tomorrowなどとして,未来の時刻を指定します. ファイルの更新 作業ディレクトリにおいてファイルを編集し,それをリポジトリ(CVSサーバ)に反映させたい場合には,作業ディレクトリ内でcvs commitを実行します. cvs commit 特定のファイルだけを反映したい場合は以下のようにファイル指定することも可能です。 cvs commit mod-file.f90 cvs commitをすると,環境変数 CVS_EDITOR で設定したエディタ (設定してない場合は環境変数 EDITOR で設定したエディタ.両方共設定してない場合はシステムが設定したエディタ) が立ち上がりますので,変更点などを書いてセーブしてください. ファイルの同期 自分の作業ディレクトリの内容を,CVSサーバの最新の内容にアップデートしたい場合には,作業ディレクトリ内でcvs updateを実行します. updateにはオプションは必須ではありませんが,何もオプションを付加しない場合には,そのプロジェクトに新たに追加されたディレクトリを取得することができません. ゆえに,常に-dオプションを付けるようにしてください. cvs update -d ファイルの追加 リポジトリに新たにファイルを追加したい場合には,まずは作業ディレクトリ内でcvs addを実行します. 例えば,new-file.c というファイルをリポジトリに追加したい場合には,以下のようにします. cvs add new-file.f90 cvs addをしただけでは,リポジトリにはファイルが追加されません. 続いて作業ディレクトリ内でcvs commitを実行します. cvs commit これで,リポジトリにファイルの追加が行なわれたはずです. なお,ディレクトリの追加も同様に行ないます. 但し,追加されるのは空のディレクトリだけで,ディレクトリの中のファイルは追加されません. 別途cvs addでファイルの追加を行なって下さい. ファイルの削除 リポジトリに登録してあるファイルを削除したい場合には,まずは作業ディレクトリ内でcvs removeを実行します. このとき,削除するファイルは作業ディレクトリから削除されている必要があることに注意して下さい. 例えば,del-file.c というファイルをリポジトリから削除したい場合には,以下のようにします. cvs remove del-file.f90 cvs addと同様,cvs removeをしただけではリポジトリからファイルは削除されません. 続いて,作業ディレクトリ内でcvs commitを実行します. cvs commit これで,リポジトリからファイルが削除されたはずです. また,ディレクトリの削除も同様に行なえますが,一旦リポジトリ内に登録されたディレクトリは削除されることはありません. 空のディレクトリが残り続けます. ゆえに,ディレクトリを追加する場合は,十分気をつけて行なって下さい.
https://w.atwiki.jp/kurosuke_se_zi/pages/11.html
CVSに関して CVS CVSは古い? いまやsubVersionか? ⇒2012年現在、subversionもすでに古いな。 最近はGITが結構はやっている。 分散レポジトリタイプですね。 そのうちメモを書くかも。 GUIクライアント WinCVSしかGUIクライアントがないかと思っていたら SmartCVSなるものを発見。 これをちょっと試してみるのも面白いかもしれない。 ちなみに無料版と有料版あり。 http //www.smartcvs.com/index.html さらにSubVersion版も有り少し私の中で熱い存在。
https://w.atwiki.jp/n-3104/pages/29.html
CVSサーバ構築インストール リポジトリの構築 xinetdへの登録 ユーザの登録 参考 EclipseからCVSサーバに接続Webアプリの開発 EclipseとCVSサーバの対応状況 CVSサーバ構築 インストール CDの2枚目に入っているrpmファイルをインストールするだけ。 # rpm -ivh /mnt/cdrom/RedHat/RPMS/cvs-1.11.2-10.i386.rpm リポジトリの構築 リポジトリ用のディレクトリを作って初期化するだけ。今回は /var/cvs/A と /var/cvs/B という2つのリポジトリを作ることにした。 # mkdir /var/cvs/A /var/cvs/B # cvs -d /var/cvs/A init # cvs -d /var/cvs/B init cvs init はCVSリポジトリとして必要なCVSROOTディレクトリや各種ファイルを生成してくれるだけ。どこか別のディレクトリに情報を書き込んだりはしていない。よってバックアップをしたければ、リポジトリのディレクトリを丸ごとコピーしてtarで固めておいたりすればよい。 xinetdへの登録 cvsはxinetdを使って公開する場合はxinetd用の設定ファイルを作成する必要がある。 # vi /etc/xinetd.d/cvspserver /etc/xinetd.d/cvspserverの中身 # cvspserver service cvspserver { socket_type = stream wait = no protocol = tcp user = root server = /usr/bin/cvs server_args =-f --allow-root=/var/cvs/A --allow-root=/var/cvs/B pserver disable = no } 設定ファイルを作成したら、xinetdを再起動する。 # /etc/init.d/xinetd restart ユーザの登録 CVS用のユーザはLinux上のユーザが利用されるが、それとは別にCVS専用のユーザを作ることも出来る。この場合は、CVS専用のユーザをLinuxのユーザに割り当てるという考え方になる。よって、まずはLinux上にCVS用のユーザを作成し、このユーザにリポジトリディレクトリへの書き込み権限を付与する必要がある。 # useradd cvs # cd /var/cvs # chown -R root cvs A B # chmod 775 A B CVS用のユーザを作るには、CVSROOTディレクトリの下に"passwd"という名前のファイルを作ればよい。書式は以下の通りである。 CVSユーザ名 パスワード Linuxのユーザ名 ユーザの追加においては再起動は必要ない。 参考 オブジェクトワークス(NRI)が公開しているガイドがとても分かりやすい。 参考:http //works.nri.co.jp/service/documents.html の「CVS on RedHat Linux 環境構築ガイド」 EclipseからCVSサーバに接続 Webアプリの開発 tomcat-pluginを利用した場合、自動的にworkフォルダ用の.cvsignoreを生成してくれるため、初回に以下のファイルをテキストとして登録するだけでとりあえず使えそう。ちなみに、classファイルについては無視するリソースに設定が見当たらないが、なぜか除外してくれる。 *.jsp .tomcatplugin EclipseとCVSサーバの対応状況 EclipseのCVSクライアントとCVSサーバの対応状況はeclipse.orgのCVS FAQで確認できる。 http //wiki.eclipse.org/index.php/CVS_FAQ#What_server_versions_of_CVS_are_supported_by_Eclipse.3F
https://w.atwiki.jp/ochamemo/pages/26.html
オチャメモ 使い方 cvs-status ワークディレクトリを指定 ワークディレクトリ内の状態が一覧表示される 内容 操作 備考 一覧表示 M-x cvs-status 全ファイルが表示される。ただしUnknownファイルは表示されない 状況確認 M-x cvs-examine 変更や追加されたファイルのみ表示される 更新 M-x cvs-update or g リポジトリから最新を持ってきてローカルとマージ コミット cvs-examine後、コミットしたいファイルをマークして"C" コミット前には更新しておくこと。全体に対してはどうやる? 追加 cvs-examine後、追加したいファイル上で「a」 Unknownが表示される 変更の放棄 放棄したいファイル上で「U」もしくはマークしてから「U」 削除 削除したいファイル上で「r」。物理ファイルも削除される diff cvs-status後、表示したいファイル上で「=」 特定リビジョンとのdiffは履歴を表示させてから対象リビジョン上で「=」押下 履歴 cvs-status後、表示したいファイル上で「l」 特定リビジョンを持ってくる cvs update -p -r リビジョン ファイル ファイル コマンドしかない?普通に取るとスティッキータグがつくので標準出力にだす。PCL-CVSでのやり方がわからない。。。 特定リビジョンを表示 履歴表示後、リビジョン上で「f」 examine表示時にコミットマークを消す x マークが邪魔のときにでも。。。いらない? 変更を取り消す cvs update -C -l -d -P ファイル名 全マーク 「M」 - ALT+bs 注意事項 commit前には一度ログ表示してみて、ファイル個別のログが表示されるか確認したほうが良い。-全体のログが表示されてしまうときは要注意。やり直したほうが良い。さもないと全ファイルにcommitがかかる。 他にもcommit前には、cvs-examineをやり直したほうが良いかもしれない。 とにかくcvs-status上でリポジトリ操作はやめたほうが良い。 ファイルを何も変更せずにタイムスタンプを変更した場合、Modifiedマークがつくがcvs-examineもしくはcvs-statusすれば、マークは消える(中身の違いをきちんと見ている)。 インストールなど debianだとpcl-cvsは入っていた。(emacs21から標準らしい) キーバインドなどhttp //www4.kcn.ne.jp/~boochang/emacs/pcl-cvs-vc.html 説明は以下のほうが詳しい。ただしここで説明されているPCL-CVSパッケージはAPTリポジトリには存在しない模様。http //www.ep.sci.hokudai.ac.jp/~morikawa/memo/cvs_emacs.txt
https://w.atwiki.jp/ochamemo/pages/20.html
オチャメモ よく使う [#w3ac450c] 更新 [#f5f495e9] チェックアウト(別名) [#m1dc6413] レポジトリのトップレベルよりも深い階層のプロジェクトの場合 [#e8fc3fdb] チェックアウト(タグ指定) [#rd87bfa2] タグ打ち [#e0e619e4] タグの移動 [#l0426018] ファイルを削除したくなった [#d392b885] ADDしたファイルを削除したくなった [#o011b736] ディレクトリを削除したくなった [#x41ed777] 作業領域の削除 [#m3dc5226] チェック系 [#q9b6f41a] 比較 [#ucb59318] 特定のバージョンとの比較 [#kf44b6db] 特定のタグとの変更点をチェックしたい [#oc9b890d] ブランチしたファイルとの変更点をチェックしたい [#sa78895b] 状況を把握 [#zab1e39b] リリースタグ一覧 [#hf0db72b] やり直し系 [#a100d7fb] 変更の取り消し [#s9710bde] 削除したファイルを復活したくなった [#t9738115] 特定のリビジョンでローカルファイルを上書きする [#l457b7fc] ヘッドから最新 [#u5e6d8e0] コマンドライン上でのCVS置換 [#g97fcee7] ブランチ系 [#s545bc4a] ブランチ [#b5105aac] tag系 [#ve1a7c33] rtag系(使いづらい) [#j05b57db] タグからブランチを切る。 [#v54f7e6e] 本流の変更をブランチに取り込む [#m43fa355] ブランチを本流へマージ [#u40afa13] チェックアウト(ブランチ) [#r272b58c] たまに [#v7ac551f] インポート [#xf0164ed] エクスポート [#xf0164ed] バイナリで登録されてるのかどうかをチェックしたい [#pd395fa7] アスキーで登録したファイルをバイナリに変更したい [#r2c3e430] バイナリの拡張子を登録する [#a1adb902] ディレクトリをまるごと追加する [#jfb86632] その他 [#t54b9c8d] コマンドを試す [#c51edc2d] 競合時の手動マージの方法 [#g5defc90] .#ファイルについて [#ga371f28] コミットやブランチなどコマンドが失敗する [#t89a354b] CVSディレクトリを削除したい [#vd5fb394] タグについて [#w7fa6762] よく使う 更新 cd 作業ディレクトリ cvs update -d -P オプションの意味--d デイレクトリを作成 P 空ディレクトリは削除 チェックアウト(別名) たとえばCVS_REPO/hoge_projを/hoge/work/にチェックアウトしたいなら cd /hoge/work してから以下のコマンド cvs co -d "hoge" -P -A "hoge_proj" /hoge/work/hogeディレクトリを作ってそこにチェックアウトされる オプションの意味 d デイレクトリを作成 P 空ディレクトリは削除 A スティッキータグを削除 レポジトリのトップレベルよりも深い階層のプロジェクトの場合 たとえばCVS_REPO/hoge/fuga_projを/hoge/work/にチェックアウトしたいなら cd /hoge/work してから以下のコマンド cvs co -d "fuga" -P -A "hoge/fuga_proj" /hoge/work/fugaディレクトリを作ってそこにチェックアウトされる チェックアウト(タグ指定) チェックアウトしたいディレクトリに移動する。 hogeプロジェクトのHOGEタグをhoge_dirにチェックアウト。 cvs co -r HOGE -d "hoge_dir" "hoge" タグ打ち タグを打ちたいディレクトリに移動 cvs -q tag リリース名 タグの移動 cvs -q tag -F リリース名 ファイルを削除したくなった 実際のファイルを削除してからCVS上で削除。 rm hoge cvs rm hoge その後コミットすること cvs ci hoge 実際にはこっちのほうが楽 cvs remove -f hoge オプションの意味--f 削除する前にファイルを消去 ADDしたファイルを削除したくなった 通常の削除と同じ ディレクトリを削除したくなった CVSは使用上、リポジトリからディレクトリを削除できない。 作業ディレクトリのディレクトリを削除したいときは、 そのディレクトリ内のファイルをすべてcvs削除しておけば、 次回更新時にディレクトリを削除してくれる。 cvs remove -fR ディレクトリ名 オプションの意味--f 削除する前にファイルを消去 R ディレクトリ内のファイルを再帰的に削除する 最後に、以下をしたほうがいいかも。 cvs delete hoge_dir 作業領域の削除 作業領域のひとつ上の階層で cvs release -d hoge 確認プロンプトがでるのでyを押下する hogeはディレクトリ名 チェック系 比較 cvs diff ファイル この場合、ローカルのファイルを修正してなければ、最新に変更があっても 差異は表示されない。 最新と比較したい場合は cvs diff -r HEAD ファイル とする 特定のバージョンとの比較 1.1 から 1.2への変更点を知りたい。 cvs diff -r 1.1 -r 1.2 ファイル 特定のタグとの変更点をチェックしたい cvs -n update -r タグ名 ブランチしたファイルとの変更点をチェックしたい これは当該ブランチの最新版との比較であり、本流の最新との比較ではないので注意。 cd branch cvs diff -u -r HEAD hoge.txt 本流との比較をしたい場合は以下。 cd branch cvs diff -u -Dnow hoge.txt 状況を把握 cvs -n update こっちのほうがいいらしい cvs -f -n update -d -P オプションの意味 n ディスクに書き込まない f 強制的に最新 d ディレクトリを構築 P 空ディレクトリは削除 これでもいいかも。かなり冗長だけど。 cvs diff . リリースタグ一覧 タグを見たいディレクトリに移動して cvs log . 2 1 |grep release*|sort|uniq|more ※もっといい方法ないかな やり直し系 変更の取り消し cvs update -C -l ファイル名 オプションの意味--C 手元で修正されたファイルをリポジトリの無修正のもので上書きします l 再帰処理を禁止。ローカルのみ 削除したファイルを復活したくなった cvs removeしたファイルの復活方法。 hogeファイルを復活したい場合。コミット前のみ有効。 cvs add hoge コミットしてしまった場合は、一つ前のバージョンをチェックアウトし、それを新規にaddするしかない。 特定のリビジョンでローカルファイルを上書きする cvs update -p -r リビジョン ファイル ファイル オプションの意味--p 標準出力に出力する r リビジョン番号(タグでもOK) ヘッドから最新 cvs update -C -d -P "hoge" オプションの意味--C 手元で修正されたファイルをリポジトリの無修正のもので上書きします。 d リポジトリに存在し、作業ディレクトリに無いディレクトリを作成します。 P 空になったディレクトリを削除 (prune) します。 以下の方がらくかも cd モジュールディレクトリ cvs update -C -d -P コマンドライン上でのCVS置換 cvs update -C -d -P "プロジェクト名" オプションの意味--C 手元で修正されたファイルをリポジトリの無修正のもので上書きします。 d リポジトリに存在し、作業ディレクトリに無いディレクトリを作成します。 P 空になったディレクトリを削除 (prune) します。 ブランチ系 ブランチ tag系 ブランチしたいディレクトリに移動して cvs -q tag -b タグ名 rtag系(使いづらい) hogeプロジェクトに対してHOGE_BRANCHを切るcvs rtag -b HOGE_BRANCH "hoge" タグからブランチを切る。 hoge_pプロジェクトのhoge_tタグからhobe_bブランチを切る。 cvs rtag -b -r hoge_t hobe_b hoge_p 本流の変更をブランチに取り込む hoge(ブランチ)のディレクトリに入る cvs update -d -P -j HEAD オプションの意味 d デイレクトリを作成 P 空ディレクトリは削除 ブランチを本流へマージ j branch オプションが1つだけだと、枝の分岐点と枝の最新リビジョン間の違いを (あなたの作業コピーに) マージします。 cvs update -d -P -j ブランチ名 オプションの意味 d リポジトリに存在し、作業ディレクトリにないディレクトリを作成する P 空のディレクトリを削除する ただし、この方法は最初の一回だけにしたほうが良い。マージを繰り返す場合は以下。 cvs update -j LAST_TAG -j HOGE_BTAG hoge.txt チェックアウト(ブランチ) hogeプロジェクトのHOGE_BRANCHをhogeworkにチェックアウト cvs co -r HOGE_BRANCH -d hogework "hoge" たまに インポート tmp_projectディレクトリ以下ををhoge_projectとして登録したい場合 cd tmp_project cvs import -m "" "hoge_project" hoge fuga -m "" メッセージ "hoge_project" リポジトリパス(どこにこのモジュールを格納するか) hoge ベンダータグ名(モジュール作成者の識別子となる) fuga リリースタグ名(外部向けのリリース) エクスポート その1。チェックアウトと基本的に同じ。 coがexportになっただけ。 cvs export -d hogework "hoge" その2。ブランチからエクスポート。 cvs export -r HOGE_BRANCH -d hogework "hoge" その3.最新のリポジトリ"hoge"をCVSディレクトリを外してコピーしたい日付を未来の日付にする cvs export -D "2010-07-07" -d 出力ディレクトリ "hoge" バイナリで登録されてるのかどうかをチェックしたい cvs status で表示される「Sticky Option」に「-kb」があればバイナリとして登録されている cvs status hoge.jar =================================================================== File hoge.jar Status Up-to-date Working revision 1.1.1.1 Wed Mar 29 08 38 59 2006 Repository revision 1.1.1.1 /home/hoge/CVS/hoge Sticky Tag (none) Sticky Date (none) Sticky Options -kb アスキーで登録したファイルをバイナリに変更したい 下記は、ディレクトリに対しても有効(hoge.binをディレクトリに置き換える) cd 作業ディレクトリ cvs admin -kb hoge.bin cvs update -A hoge.bin cp src-hoge.bin hoge.bin # 壊れてない元ファイルをコピー cvs commit -m "reset -kb flag" オプションの意味 A スティッキータグを削除 バイナリの拡張子を登録する cd /tmp cvs co CVSROOT vi cvswrappers *.gif -k b *.jpg -k b *.jpeg -k b *.png -k b *.ico -k b *.jar -k b *.idx -k b cvs commit cvswrappers ディレクトリをまるごと追加する ひとつづつ追加するしかないらしい もしかしたらcvs importでやる? その他 コマンドを試す よくわからないコマンドを試すときに-nすれば安心かも cvs -n hogehoge 競合時の手動マージの方法 hoge.jsp ABC ======= abc 1.13.2.4 この場合、==== を境に上がローカルの修正、下がマージもと果の修正になる。 どちらを採用するかを手動で決める。 .#ファイルについて updateすると勝手に「.#ファイル名」というファイルが作られるがこれは、CVSがつくるバックアップファイル。 コミットやブランチなどコマンドが失敗する ブランチを切ろうとすると、以下のようなエラーが出る。 $ cvs rtag -b dev_searchtop_from_release20060712 "web/ver_06_04s" cvs rtag [10 52 58] waiting for tech s lock in /home/tech/CVS/web/ver_06_04s/img/bg 原因なぜか、リポジトリ内に、ロックファイルがあった為。#で始まるファイル。-対処#で始まるファイルがロックファイルなのでこれを削除する。 CVSディレクトリを削除したい cd 作業ディレクトリ find . -type d -name CVS |xargs rm -rf タグについて タグは、ブランチごとにあるのではなく、すべてのブランチに対してグローバルである したがって、全てのブランチを通してユニークになるように注意する
https://w.atwiki.jp/hideologie/pages/5.html
歴史的には、unixの黎明期から、簡易なバージョン管理ツールは幾つか存在していた。 RCS ファイルベースのバージョン管理 管理対象について、同じディレクトリの、似たファイル名で、バージョン管理ファイルを置く 編集するファイルは、予め「編集予定である」というマークを付けなければならない。これはロックとして働く。同じファイルを他の作業者が別の修正を加えたい場合はどうするのか?というか無理。ロックしたまま退社すると最悪。知らないけど。 CVS RCSでの反省を踏まえて、RCSから技術的にあまり逸脱せずに、 複数人数での開発を可能にしたのがCVSであると言える。 ファイルベースのバージョン管理 バージョン管理ファイルは、一箇所のCVSサーバに、集中管理するリポジトリと呼ぶ 特にファイルをロックしなくても、編集を登録できる これらのお蔭で、CVSによる中規模以上の開発が可能になると、新たなる問題が浮き彫りになる。 複数の人間が同じファイルに別系統の修正をした場合の対処CVSはファイルベースであるため、編集を先に登録してしまうと、次の人はまずその変更を取り出して、自分がする筈だった編集と、手動で併合しなければならない。
https://w.atwiki.jp/wiki3_nab/pages/42.html
概要 CVSを使ってホームディレクトリ下のdotファイル等を管理する。 計画 ホームディレクトリ全体を対象にすると収集がつかなくなるので、一部のファイル/フォルダのみを対象とし、下記の通りに管理する。 CVSの管理対象とするファイルはフォルダ毎に整理し、~/cvs下にフォルダごと置く。---(A) CVSへの登録は(A)のフォルダ単位で行う (A)のフォルダ内のファイルを本来配置すべき場所には代わりにリンクを作成する---(B) (B)のリンクの作成はシェルスクリプトにしておく 手順 1)準備 cvsサーバー側の詳細は省略。今回はクライアント側の説明のみ。cvs自体はデフォルトで入っているのでインストール不要。環境変数CVSROOTをサーバーにあわせて設定しておく。ssh接続するならCVS_RSHも忘れずに設定する。 ~/.profileの記述例 # 実行ホストがCVSサーバーの場合のみローカルディレクトリを参照。 if [ `hostname` == "CVSサーバー名" ]; then export CVSROOT=/サーバー内の/フォルダ else export CVSROOT= ext 接続ユーザー名@CVSサーバーアドレス /サーバー内の/フォルダ export CVS_RSH=ssh fi; 2)管理対象とするファイル/フォルダをCVSに登録 ここでは、~/bin/内のファイルを管理対象にする、と仮定します。下記のコマンドでCVSサーバーに新規登録。今後はリポジトリ名でファイルをやりとりするので、後で思い出しやすい名前にしておく。ユーザ名とリリース名は適当。 cd ~/cvs/bin cvs import -m "コメント" リポジトリ名(登録名) ユーザ名 リリース名 例) cvs import -m "~/bin added" home.bin bin1 start 3)~/cvs以下にcheckoutする mkdir -p ~/cvs/ cd ~/cvs cvs co home.bin とりあえずこれでCVSに登録はできているのですが、~/bin/*と~/cvs/home.bin/*は名前は同じでも完全に別物です。 4)~/cvs/bin/*のリンクを~/binに作成する 下記のシェルスクリプトを作成し、実行権を与えておく。lncvs-home.bin.shを実行すると、~/cvs/home.bin/内のファイルへのリンクを~/binに作成します。~/bin内に同名ファイルがある場合は削除されますので注意。 ~/bin/lncvs-home.bin.sh #!/bin/sh lndir.sh ~/cvs/home.bin/ ~/bin/ ~/bin/lndir.sh #!/bin/sh ########## # define functions # error print ERROR_EXIT(){ echo "usage lndir.sh [-s|-h] fromdir todir" echo "lndir.sh make links recursively." echo "-s symbolic link (default)" echo "-h hard link" exit 2 } # make links recursively LINK_RECURSIVE(){ for i in $1/.* $1/*; do SRC=$i DST=`echo $i | sed "s#$SRCBASE#$DSTBASE#"` NAME=`echo $i | sed s#.*/## ` if [ -d $SRC -a $NAME != "CVS" -a $NAME != "." -a $NAME != ".." ]; then mkdir -p $DST LINK_RECURSIVE $i elif [ -f $SRC ]; then #if [ -e $DST ]; then rm $DST; fi #ln -s $SRC $DST $LN $SRC $DST fi; echo $SRC done }; ########## # initialize # getopt args=`getopt sh $*` LN="ln -fs " if [ $? -ne 0 ]; then ERROR_EXIT; fi set -- $args for i; do case "$i" in -s) # symbolic link LN="ln -fs " shift;; -h) # hard link LN="ln -f " shift;; --) shift; break;; esac done # set global variables if [ $# != 2 ]; then ERROR_EXIT; fi SRCBASE=`echo $1 | sed s#/$## ` DSTBASE=`echo $2 | sed s#/$## ` if [ $SRCBASE = $DSTBASE -o ! -d $SRCBASE ]; then ERROR_EXIT; fi; # debug print #echo "1st "$SRCBASE #echo "2nd "$DSTBASE #echo $LN #exit 1 ########## # main LINK_RECURSIVE $SRCBASE exit 0 5)home.bin回りの操作 他の端末で同じファイルを使いたい mkdir ~/cvs ~/bin cd ~/cvs cvs co home.bin cp ~/cvs/home.bin/* ~/bin ~/bin/lncvs-home.bin.sh 現在の状態をcvsサーバーに反映する cd ~/cvs/home.bin cvs ci CVSサーバーの最新版を現在の端末に反映する cd ~/cvs/home.bin cvs up 管理するファイルを追加する cp 追加するファイル ~/cvs/home.bin/ cd ~/cvs/home.bin cvs add 追加するファイル cvs ci 6)ドットファイルの管理 基本的な作業は上記と一緒。うちでは~/cvs/home.dotを作成し、管理したいファイルだけをこの中に置いている。~/cvs/home.dot/内のファイルのリンクを~/に作成するのは次のスクリプトを使用。 ~/bin/lncvs-home.dot.sh #!/bin/sh lndir.sh -h ~/cvs/home.dot/ ~/ chmod 710 ~/.fetchmailrc chmod 600 ~/.ssh/* chmod 700 ~/.mutt chmod 700 ~/.resources chmod 600 ~/.vnc/passwd chmod 700 ~/.gaim chmod 700 ~/.jpilot こんな風に、パーミッション設定等を変更する作業もこのスクリプトの中に書き込んでおく。 メモ、注意事項 X11付属のlndirは使ってない。なんでだったっけかな。理由は忘れた。 リンク作成はソフトリンクの方が好き。CVSでの管理対象になってるかどうか分かりやすいから。 問題点、課題 もっとスマートな方法があるような気がしてならない。
https://w.atwiki.jp/ochiwiki/pages/1193.html
CVS OKUYAMA 2013年夏合宿の宿の近くにあったコンビニのようなもの 夜の8時までなら買ったものを宿に配達してくれる お土産から食品まで幅広いものを売っているが、冬季限定のお菓子が夏に置いてあったりする 店長の奥山さんが都都逸をたくさん知ってる 恐らく落研の奥山さんの親戚ではないと思われる CVSは多分ConVenice Storeの略
https://w.atwiki.jp/kh_0/pages/42.html