最初の情況:
Dropboxでとりあえず複数PC間でソースファイルの共有はできている。
PC_Aで編集したりPC_Bで編集したりする分には問題ない。
バックアップもDropboxのサーバーにあるのでとりあえずは安心。

さらなる要望:
リスク管理のためにソースファイルのバージョン管理をしたい。

とりあえず、最初はsvnのレポジトリを学校のサーバーにつくって
Dropbox中のプロジェクトをそこにコミットしてやればバージョン管理できるかなと
考えてそのとおりにやってみました。
PC_Aだけで編集したりコミットしたりする分には問題なくバージョン管理できて、
Dropboxでの共有もしてくれました。
でもPC_Bで編集してPC_Aでコミットとかごちゃごちゃしたことをしだすと
.svnフォルダの中がおかしくなるのかコミットできなくなりました。
そもそもDropboxと学校のサーバー、二つもサーバーがあるのもごちゃごちゃしてよくない。

そこでsvnを使用するのをやめて、分散バージョン管理のGitを使用することにしてみました。
Gitはレポジトリのコピーをそれぞれの編集者がローカルに持ち、
普段はそこにコミットしてバージョン管理をし、
それらの変更を他のメンバーと共有したいときは、共有のマスターレポジトリに
ローカルのレポジトリをpushすることで共有をするもののようです。
他人の編集結果を自分のリポジトリに反映するときはマスターからpull。
ローカルのレポジトリと、共有のマスターレポジトリの二つがあるのがポイントですね。

んで、自分の目的のために使ってみる。
ローカルのレポジトリをDropbox中のソースフォルダの中の.gitフォルダに作成。
当然Dropboxで同期される。
PC_AでEclipseのEGitでコミット。
PC_BでDropboxの同期が終了したあとにリフレッシュしてやれば、
ちゃんとPC_Aでの変更やコミット履歴が参照でき、そのまま編集できる。
(必要なもの全部まるまるコピーしてるんだから当然といえば当然)
Dropboxでソースファイルを共有し、バージョン管理もしたいという目的は達せられました。
めでたしめでたし。

なのですが、気になったのはこの僕のGitを用いた一連の作業にpush/pullが登場しないこと。
他のブログを覗いてみると、マスターリポジトリをDropbox中に作成し、
Dropboxの外にソースやローカルリポジトリを作って
push/pullをするという方法をとってる人が多かったんですよね。
そっちじゃなきゃなにか問題あるのかなあ、といろいろ考えたのですが、
僕の結論は以下の感じ。

マスターリポジトリだけをDropbox中におくと、pushした時だけ同期が起こる
(当たり前。通信は最小限で済む)
Dropbox中にソースを起き、そこにレポジトリもつくると編集・コミットのたびに同期が起こる
(人によっては嬉しくないかも。同期の時間もかかるし。)
そもそもGitの元々の思想は共有するのはマスターレポジトリなので、
それだけをDropboxにおいて共有するって考え方は自然で僕のとった方法のほうが邪道かも。

ただ僕の方法だとちょっとした変更でもにいちいちpush/pullする必要ないし、
てかpush/pullするの面倒だしバージョン管理もローカルリポジトリで十分出来てるし
僕自身にはこっちのほうがあってる気がします。
まあ同期が被いとPC付けてすぐ作業できない問題と、
Dropboxによるファイルロックが妨げに成る可能性がありますが・・・

長々と書いたけどGitはすごく便利みたいです。Dropboxと組み合わせると特に。

そのうち真面目にDropboxの記事も書いて招待で容量ウハウハとかやりたいと思ってる今日この頃。