svn その３ 課題リストを消化するんご
■検証環境
・svn server
CentOS6.9、192.168.2.26、プロンプト：せ6>、リポジトリのパス：/var/svn/repos/project
svnサーバ起動
せ6> service svnserve start
・svn client A
CentOS7.3、192.168.2.7、プロンプト：せ7>、リポジトリのパス：/svn/project
・svn client B
OpenSuSE11.4、192.168.2.11、プロンプト：すぜ>、リポジトリのパス：/svn/project
■検証
２．ローカルリポジトリ内のファイルやディレクトリの追加、削除
・リポジトリに含まれると認識されるファイルやディレクトリとは？
・リポジトリに含まれると認識されないファイルやディレクトリとは？
・ローカルリポジトリの場合と、リポジトリサーバの場合の違い
→リポジトリサーバはクライアントからのsvn create、svn add、svn ciなどの更新系コマンドによる追加や削除のみが許される。
その際に、排他制御、バージョン管理が行われる
【ポイント】
・リポジトリサーバではどうなるのか？
・ローカルリポジトリbではどうなるか？
・上記が行われた後、bはどうするのか？
・ローカルリポジトリaはその後普通に行くのか？
・ログやバージョン情報はどうなるの？
【検証2-1】 aが新しいファイルやディレクトリをリポジトリに追加
・ファイルシステム上に普通のOSのコマンドでファイルを新規作成して、svn addで登録する。
svnサーバ上のリポジトリに登録する際には、さらに svn ci でコミットする必要がある。
※リポジトリにすでに登録済みのファイルをコピーしたり移動してパスを変更した場合は、リポジトリにはまだ登録されていないファイルと見なされるので、これらのファイルも svn add で登録する必要がある。
※すでにリポジトリ上に登録済みの同名のファイルを同じパス上に新規作成、コピー、あるいは移動した場合は、このままでは svn add しようとするとコンフリクトするので、一旦、ファイル名を変更して保存し、svn update してリポジトリから同名のファイルを取得して内容を見てから、新規作成しようとしているファイルをリポジトリ登録済みのファイルをmergeする。
・ディレクトリ内にサブディレクトリやファイルがある状態で、ディレクトリをsvn addしたら、ディレクトリとその配下のサブディレクトリ及びファイルがすべて一度にsvnに登録される。
【検証2-2】 aがリポジトリ内のファイルを削除
・rmコマンドで削除してもリポジトリから削除したことにはならず、svn update したら、同名のファイルがまたあらわれる。リポジトリからも削除したい場合は、svn updateですべての更新が反映された最新リビジョンにしたうえで、svn delで削除して、すかさずsvn ciでリポジトリからの削除を反映させる。ただし、先述の通り、svn delで作業コピーから削除した時点で最新リビジョンでなかった場合、svn ciしようとしたら、コンフリクトが発生するので、一旦svn delしたことを
svn revert で中止してからsvn upして念のため、削除しようとした時点以後に他者によって変更された内容を確認してから再度 svn delでリポジトリから削除をして、この削除をコミットする。
・ディレクトリ内にサブディレクトリやファイルがある状態で、ディレクトリをsvn delしたら、ディレクトリとその配下のサブディレクトリ及びファイルがすべて一度に削除される。
※すかさずsvn ciしないと、削除操作がコンフリクトになるのは上記と同様。
【検証2-3】 リポジトリ内のファイルのシンボリックリンクもリポジトリ内に含めることはできるのか？
すぜ> pwd
/svn/project/trunk
すぜ> ll
・・・前略・・・
-rw-r--r-- 1 root root 1649 May 3 19:35 passwd
・・・後略・・・
すぜ> ln -s passwd passwdln
すぜ> svn ci -m ""
すぜ> svn st -v
・・・前略・・・
? passwdln ←シンボリックリンクはsvn登録外
・・・中略・・・
42 41 centos7 passwd ←実ファイルはsvn登録済み
・・・後略・・・
すぜ> svn add passwdln
A passwdln
すぜ> svn st -v
・・・前略・・・
A 0 ? ? passwdln ←シンボリックリンクがsvn登録された。ただし、ローカルリポジトリ上のRv.=0、リポジトリ上のRv.はまだ無し
・・・後略・・・
すぜ> svn ci -m "" passwdln
Adding passwdln
Transmitting file data .
Committed revision 43.
すぜ> svn st -v
・・・前略・・・
43 43 suse passwdln ←シンボリックリンクがsvnにコミット。ローカルリポジトリ上もリポジトリ上もRv.=43
・・・後略・・・
せ7> pwd
/svn/project/trunk
せ7> svn up
Updating '.':
A passwdln
リビジョン 43 に更新しました。
せ7> svn st -v
・・・前略・・・
43 43 suse passwdln ←シンボリックリンクも実ファイルと同じようにsvnに登録できる
・・・後略・・・
せ7> ll
・・・前略・・・
-rw-r--r--. 1 root root 1649 5月 3 19:30 passwd
・・・中略・・・
lrwxrwxrwx. 1 root root 6 5月 3 20:22 passwdln -> passwd ←リポジトリ内の実ファイルへのシンボリックリンクとして機能
・・・後略・・・
【検証2-4】 リポジトリに含まれないファイルやディレクトリのシンボリックリンクをシステム内に張ったらどうなるか？
OpenSuSE11.4には存在してCentOS7には存在しない /etc/sysconfig/clock
のシンボリックリンクをsvnに登録してみる
すぜ> ln -s /etc/sysconfig/clock clock
すぜ> ll
・・・前略・・・
lrwxrwxrwx 1 root root 20 May 3 20:29 clock -> /etc/sysconfig/clock
・・・後略・・・
すぜ> svn add clock
すぜ> svn ci -m ""
Adding trunk/clock
Transmitting file data .
Committed revision 44.
せ7> svn up
Updating '.':
A clock
リビジョン 44 に更新しました。
せ7> ll
・・・前略・・・
lrwxrwxrwx. 1 root root 20 5月 3 20:31 clock -> /etc/sysconfig/clock ←リポジトリ外の実ファイルへのシンボリックリンクはリンク切れになったがsvnへは普通に登録可能
・・・後略・・・
【検証2-5】 ハードリンクはどうなるのか？
・あるクライアントの作業ディレクトリでハードリンクを作成してsvn addしてcommitしたら、ハードリンク元と同じ内容のファイルとしてsvnに登録される。別のクライアントで取得したらハードリンクではない（ハードリンク元とinode番号が異なる）が内容が同じファイルとしてコピーされた。
・OpenSuSE11.4でリポジトリ内に/etc/sysconfig/clockファイルのハードリンクを作成して、リポジトリに登録してコミットしたら、システム内に/etc/sysconfig/clockファイルがないCentOS7側の作業コピーにこのハードリンク元の/etc/sysconfig/clockファイルと同じmd5sum値のファイルがコピーされた
【検証2-6.5】 システム内の適当なディレクトリをマウントポイントにして外部ファイルシステムをマウントした場所に作業コピーを作成したらどうなるのか？
・loop backデバイスを作成して適当なマウントポイントにマウントして作業コピーをチェックアウトする。
すぜ> dd if=/dev/zero of=/tmp/raw bs=1024k count=2000
すぜ> mkfs.ext4 /tmp/raw
すぜ> mkdir /svn/loopback
すぜ> mount -o loop /tmp/raw /svn/loopback
すぜ> cd /svn/loopback
すぜ> rm -rf *
すぜ> rsvn co svn://192.168.2.26/var/svn/repos/project/trunk
すぜ> cd trunk
上記の作業コピー内にあるファイル「piyo.data」を編集して保存
すぜ> svn ci -m ""
せ7> svn up
CentOS7側で「piyo.data」が編集されていることを確認
上記の作業コピー内にあるファイル「piyo.data」を編集して保存
せ7> svn ci -m ""
すぜ> svn up
OpenSuSE側で「piyo.data」が編集されていることを確認
・OpenSuSEで上記のloopbackデバイスをアンマウントして別のマウントポイントにマウント
すぜ> cd /tmp
すぜ> umount /svn/loopback
すぜ> mount -o loop /tmp/raw /mnt
すぜ> cd /mnt/trunk
上記の作業コピー内にあるファイル「piyo.data」を編集して保存
すぜ> svn ci -m ""
せ7> svn up
CentOS7側で「piyo.data」が編集されていることを確認
上記の作業コピー内にあるファイル「piyo.data」を編集して保存
せ7> svn ci -m ""
すぜ> svn up
OpenSuSE側で「piyo.data」が編集されていることを確認
【分かったこと】
作業ディレクトリのシステム内での絶対パスは関係ない。
【検証2-6】 リポジトリ内のディレクトリをマウントポイントにして外部ファイルシステムをマウントしたらどうなるのか？
- 外部ファイルシステム内のファイルをリポジトリに含めることはできるのか？
- アンマウントしてしまったらどうなるのか？
- ローカルリポジトリで外部ファイルシステムをマウントしてリポジトリに含めた後アンマウントしてsvn updateしたらローカルファイルシステムに最新のファイルが現れるのか？
【検証2-6-1】 すでにsvnに登録済みのディレクトリをマウントポイントにして外部ファイルシステムをかぶせてマウントしたらどうなるか？
※すでにsvnに登録済みのディレクトリを「fuga」とする
→マウント後、マウントポイントのディレクトリ「fuga」はファイルシステム管理外と認識された。
→「fuga」をsvn add 「マウントポイント」 を実行できた
しかし、リポジトリに登録済みの「fuga」および「fuga」配下のサブディレクトリおよびファイルはsvn upしてもマウントポイント「fuga」配下にコピーされなかった。
→マウントポイント「fuga」内にファイルを新規作成してsvn addしてコミットできた。
しかし、別のsvnクライアントからsvn upしても、上記で新規作成してコミットしたファイルは作業コピーにコピーされなかった。
※なんかよくわかんないけどリポジトリ登録済みのディレクトリに外部ファイルシステムをかぶせてマウントすると期待どおりの動作をしないみたいなのでこういうことはしない方がいいみたい。
【検証2-6-2】 svnに登録されてないディレクトリをマウントポイントにして外部ファイルシステムをかぶせてマウントしたらどうなるか？
※svnに登録未済のディレクトリを「puni」とする
→「puni」に外部ファイルシステムをマウントして、「puni」配下にファイルを新規作成して、「puni」ディレクトリをsvn addでリポジトリに登録してコミットした後、別のsvnクライアントでsvn upしたら、「puni」ディレクトリと配下のファイルが作業コピーにコピーされた。
→双方で「puni」配下のファイルに編集してコミットしたが普通のディレクトリ同様、svnリポジトリに登録され、リビジョン更新や作業コピーの取得ができた。
→上記を確認後、「puni」から外部ファイルシステムをアンマウントしたところ、マウントポイントのディレクトリ「puni」には当然空ディレクトリとなったが、この状態でsvn upしても、「puni」ディレクトリ配下にリポジトリに登録されているはずのファイルはコピーされなかった。
※なんかよくわかんないけどリポジトリ登録されてないディレクトリに外部ファイルシステムをマウントしてsvnリポジトリに登録しても普通のディレクトリのようにリポジトリに登録されるし、ディレクトリ配下に作成したファイルもsvnリポジトリに登録できて作業コピーも普通にコピーされるが、外部ファイルシステムをアンマウントしてしまったら期待どおりの動作をしないみたいなのでこういうことはしない方がいいみたい。
【検証2-7】 リポジトリ内のファイルやディレクトリの所有者、パーミッション
- aにはいるけど、bには居ないユーザを所有者にした場合はファイルの所有者はpidだけ引き継がれるのか？
→OpenSuSE11.4とCentOS7の２つのsvnクライアントから、svnリポジトリに登録済みの任意の2つのファイルについて、chmodとchownコマンドでファイルシステム上のパーミッションと所有者を変更して、コミットしてもう一方でsvn upを実行したが、いずれで実行した場合も、変更した所有者とパーミッション情報はコピーされなかった。
※svnではファイルシステムの所有者情報とパーミッション情報を同期しないみたい
【検証2-8】 リポジトリ内のバイナリファイル
- 別に普通か？
システム内の/bin/lsコマンドをコピーしてsvn addでリポジトリに登録してコミットした後、もう一方のsvnクライアントでsvn upを実行して作業コピーにコピーできたんご
ちなみに、作業コピーにコピーされたlsコマンドも普通に実行できた。
※そりゃそうだろwww そうじゃなきゃそもそもリポジトリの意味ないしwww
【検証2-9】 DB
- ローカルリポジトリのディレクトリにpostgresqlの$PGDATAのようなクラスタディレクトリをinitdbで作成した場合、どうなるのか？静止点つくらずに普通にファイルをコピーした状態に相当するのか？
→OpenSuSE11.4 と CentOS7の両方に、postgresql-9.4.17-2-linux-x64 をインストールして、
OpenSuSEの方でinitdbコマンドで、/svn/project/trunk/fugaにクラスタを作成して、所有者と所有グループをpostgresに変更してsvn addでクラスタディレクトリを指定したら、PostgreSQL9.4のクラスタがsvnリポジトリに登録された。そのあとコミットして、CentOS7側でsvn upして同じようにクラスタの所有者と所有グループをpostgresに変更して普通に、
pg_ctl start -D /svn/project/trunk/fuga
でクラスタを起動できた。
※あたりまえだけどｗｗｗ
※静止点うんぬんはまた次元の違う話んご