バージョン管理システムを使ったゴースト開発の方法
開発作業のすすめかた
開発用SSPを準備する
さて、ようやく準備が整いました。
ここからは普段の開発作業での使い方を説明したいと思います。
あ、そういえば言い忘れてました。
VisualSVNServerの設定画面はもう閉じて結構です。
何か問題でも起きない限り、再び開く必要もないと思います。
SVNサーバ機能自体は、サービスとして勝手に立ち上がって常時動いているので、
あの画面を普段いちいち開く必要はありません。念のため。
まずは開発用のSSPを用意します。
ネットワーク更新のテスト等を考えないのであれば、開発用として分けなくても
別に構わないのですが、筆者は分けるようにしています。
置き場所はどこでも構いません。
SSP本体を展開したら、内部のghostフォルダを開きます。
そして、フォルダ内の適当な場所を右クリックして「SVNチェックアウト」を選び、チェックアウトの画面を開きます。
ghostフォルダに開発ゴーストのデータをすべて落としてくるのが目的です。
このとき、チェックアウト先のパスの指定に注意してください。
たぶんghostフォルダの中にGhostsフォルダを作る設定になってますので、
最後のGhostsフォルダの部分は消しておきます(選択している部分)。
OKを押すと「空フォルダじゃないけどいいの？」って言われますが構いません。
OKしてしまいましょう。
完了すると、フォルダ内はこんな感じになります。
開発ゴーストのフォルダが生成されました。
それだけでなく、フォルダのアイコンが変わったことに気付くと思います。
各フォルダの左下に何か印が付いていますね。
これはSVN管理対象フォルダ内の各ファイル(フォルダ)の状態を表すもので、
緑のチェックは「管理対象/状態変更なし」、青の「？」は「管理対象外」、
今は出ていませんが赤の「！」は「管理対象/状態変更あり」を示します。
要するに、管理対象ファイルに変更を加えた場合、ここでひと目でわかるようになっています。
管理情報フォルダは先ほど見たように隠しフォルダとして生成されてますし、
エミリのフォルダにも管理対象外表示が付いていますが、ゴーストは特に問題なく起動します。
適当に何体か起動してみましょう。
エミリが即刻爆発したようですが特に問題はありません。
※チェックアウトの仕方を誤って、階層が変になった場合は、
自分のゴーストのフォルダと、隠しフォルダになっている「.svn」フォルダを
一度削除して、再度チェックアウトしなおしましょう。
ファイルを更新する
さてここからが実際の開発作業です。ようやくです。長い。
とりあえず、ランダムトークを追加してみましょう。
dic08_RandomTalk.txtを書き換えます。
きわめて適当ですね。保存してエクスプローラを見ると、
先の説明通り、さっそく赤「！」になってますね。「変更あり」というわけです。
さていきなりですが余談。今は何を書き換えたのかわかっているので問題ないのですが、
たまに「あれ？ このファイル何書き換えたんだっけ？」となる場合があります。
そういう時はファイルを右クリックして、「TortoiseSVN」から……
……なんかめっちゃ多いですね項目。とりあえず「差分を表示」を選びます。
こんな画面が表示されました。
登録されている「作業ベース」と、手元の「作業コピー」間の差が、色付きで表示されています。
こんな感じで違いのある箇所をぱっと表示してくれるわけです。
不要な書き換えをしてしまっている場合には、左側のベースの内容を
一部分だけコピーしてくるようなこともこの画面で可能です。
この辺りはいろいろ試してみてください。
※ここで自動的に起動される比較表示用のアプリは、設定で差し替えることができます。
デフォルトのものは表示にクセがありちょっと見づらいので、筆者は別途ダウンロードしたWinMergeを使用しています。
このあたりはお好みですが、デフォルトで使ってみて違和感があればとりあえずWinMergeを入れてしまうのがおすすめです。
さて次は変更内容をコミット(リポジトリに反映)します。
先ほど更新したファイルか、またはその上位のどこかのフォルダを右クリックして、
「SVNコミット」を選択します。
この辺りはすでに一度、初期リポジトリ構築のときにやってますね。
ここでは上位の「ghost」フォルダでコミットを選択してみました。
なので画面下に対象ファイルとして、下位フォルダ内の新規ファイル
(ゴースト起動時に生成されたファイル等)も一緒にずらっと表示されていますが、
これらは管理対象外であるため、デフォルトでコミット対象のチェックが付いているのは
管理対象で変更があった「dic08_RandomTalk.txt」だけです。
そういうわけで、特にコミット対象のチェックを変更する必要はありません。
くれぐれも余計なファイルはコミットしないようにしましょう。
メッセージ欄にはこんな感じで、何を変更したのかコメントを残しておきましょう。
OKを押してコミットします。
無事完了しました。リビジョン2になりました。
開発はこんな感じで進めていきます。
コミットのタイミングは自由です。
ランダムトーク1個でも別にいいし、1日の作業の終わりでも、更新直前だけでも、
区切りのよいタイミングならいつでもよいと思います。
筆者はバグ対応1件、機能修正1件、ランダムトークならある程度まとめて、程度の単位で
コミットすることが多いですが、しょせん個人での開発なので、この辺は結構適当です。
よく使う機能いろいろ
よく使う機能についてざっと述べます。
詳細な動作や、その他の機能についてはTortoiseSVNのヘルプを参照してください。
ログを表示
いつどのようなコミットを行ったのか、履歴を一覧表示します。
また表示されたファイルを選択すると、その前のリビジョンから次のリビジョンで
どう変わったのか、ファイルの差分を確認できます。
変更の取り消し
変更を加えたファイルを変更前(作業ベース)の状態に戻します。
特定リビジョンへ更新
指定した過去のリビジョンの時点のデータを取得します。
SVN更新
データを最新のリビジョンの状態に更新します。すでに最新の場合は影響なし。
変更されているファイルは更新できなかったり、内容がマージされたりします。
変更のせいでうまく更新できない場合は一度変更を取り消すなどしましょう。
削除
リポジトリ上からファイル削除する(登録を削除する)場合は、SVNのメニュー内の「削除」を選びます。
単にエクスプローラからファイル削除してしまうと単にローカルでのファイル紛失扱いになり、
登録削除にはならないので注意してください。
追加
青「？」になっている管理対象外ファイルを管理対象に含めるために使います。
これ自体はローカルの処理なので、「追加」した時点ではリポジトリには変化はありません。
次のコミットの際、デフォルトでコミット対象(チェック付き)として扱われるようになり、
コミットを行うとリポジトリに新規ファイルとして登録されます。
エクスポート
管理情報なしで、単純にリポジトリのファイルだけを落としてきます。
他にもいろいろ機能はありますが、ローカル開発だとあんまり関係ないものもあったりで、
主に使うところはこれくらいではないかと思います。
ネットワーク更新の準備
開発が一段落したら、ネットワーク更新の準備をしましょう。
これには、開発用SSPとは別にチェックアウトしたデータを使用します。
最初にリポジトリ構築に使用したデータが残っていれば、それを使っても構いません。
ない場合は、新たにチェックアウトしてください。
まずはデータを最新化します。「SVN更新」を選んでください。
無事更新が完了したら、ゴーストのフォルダをどこかのゴーストにでもぶん投げて、
ネットワーク更新用ファイルとnarを作ってもらいます。
SSPの開発用オプションはオンにしておきましょう。開発する人は普通してるかと思いますが。
結果、こんな感じで更新用ファイルが更新されます。赤くなってます。
ついでにinstall.txtが増えてますね。こいつはいらないので即刻消しておきます。
残しておくと次の更新用ファイルの作成に邪魔ですので……
(※個人的にはその程度の認識なのですが、違ったらごめんなさい)
同時にできたnarについては、これもSVN管理下にしてしまうのがよいかと思います。
私はゴーストと同階層にnarフォルダを作って放り込んでいます。
こんな感じでフォルダを作って、ファイルを突っ込んで、「追加」してしまいましょう。
あとは、ちゃんと変更をコミットして……
さて、これでネットワーク更新準備が完了しました。
あとはこのフォルダのデータをサーバに上げるだけです。
あ、SVNの管理フォルダはサーバに上げないようにしてくださいね。不要ですので。
そういえば言い忘れていました。
開発用SSPのフォルダには、テスト用の辞書とかがんがん置いちゃっても問題ありません。
コミットしない限り、ネットワーク更新準備用のチェックアウト分にはまったく影響しないので。
筆者の環境では「dic99_testDic.txt」なんてファイルが置きっぱなしです。
でも「テスト用辞書抜いたら動かなくなった」なんて話もありえなくはないので、扱いにはくれぐれもご注意を。
※参考：開発用SSPのゴーストのネットワーク更新について
開発用SSP内のSVN管理下にあるゴーストについては、
ネットワーク更新テストには使用しないほうが無難です。
ネットワーク更新のテストは、別のSSP内に同じゴーストを用意して実施してください。
開発用SSP内のSVN管理下にあるゴーストのデータ更新には「SVN更新」を使います。
もし変更がある状態でSVN管理下のゴーストのネットワーク更新を行うと、
ネットワーク更新とSVNの機能が干渉するようで、妙なエラー表示やデータのマージが発生し、
正しく更新されません。
この場合、一度SVN側で「変更の取り消し」を行うと正常化します。
たぶん、変更をあらかじめすべて取り消してからネットワーク更新をかければ問題ないはずですが、
筆者は面倒なので、やらないことにしています。
なお、開発用SSP内のSVN管理外ゴースト(エミリとか)については特に影響はありません。
普通にネットワーク更新してOKです。
つぎへ
まえへ / 最初にもどる