Subversion 総評さて、マスターアップも終わった所で、今回の開発で初めて使った Subversion の感想をまとめようと思う。まずは Subversion を導入したときの日記を参照して欲しい。なお、Subversion は以下、SVN と記す。
今回の SVN を使用したことによって、よかったなと思ったことを羅列する。
まずそもそも今回のプロジェクトでは SVN の運用に問題があった。一つはサーバの場所である。クライアントさんの所ではサーバが立てられないと言うことで、今回は amatsukami.jp サーバに SVN サーバを設置した。このため、外注さんならともかく、社内の人もいちいち amatsukami.jp サーバを経由することとなり、更新パフォーマンスが低下した。 SVN を導入して面倒だなと思ったのが、以下である。
あとは各作業メンバーが意外に SVN の利点を生かし切れてないというか、お互いがいじりそうなファイルはロックかけておこうとか言われて……いやまぁ、それでもいいんだけど、別に大幅に変わる訳じゃないんだし、ええやん、あとでコンフリクトした所を直せばさ、とか思う場面がいくつかあった。 で、いろいろ考えたんだけど、要するにさ、外注プログラマさんにとってクライアントさんの不手際が多いってことなのかナーと。プログラマがいないクライアントってことは、コンピュータに関しては無知な人が多いと予想される。そんなクライアントとやりとりをしていると、「あのファイルどこにありましたっけ?」「どれが最新でしたっけ?」「間違ってファイル消しちゃいました/上書きしちゃいました/壊しちゃいました」「FTP につながらないんですけど」などなど、などなど、そりゃもープログラマからしたら、「なんで?」って叫びたくなるようなミスが連発する。しかもさ、クライアントがミスを認めずプログラマや外注のせいにしようとするし。それをすべて吸収するのが SVN なのかなー……と、何となく思った。 まぁ、かくいうボクも今回のプロジェクトで、プログラマからは「なにやってんだコイツ?」って見られてたのかも知れないけどね(笑)。それはプログラマのみぞ知るといったところか。 今後、ボクの所に来ているいくつかの仕事の中で、SVN を使用するのが決定しているものがすでにあるので、SVN とは今後も付き合っていかないといけないだろう。そのためにはとりあえず SVN の転送速度を上げる方法を模索することだなー。正直、転送さえ速ければボクの不満点はほぼ解消される。SVN サーバはいろいろ種類があるようなので、時間ができたら調べて見ようと思う。ただ SSL や HTTP との連携の仕方とかがけっこう難しそうなんだよなー。IIS と相性悪そうだし。ポート限定して、Apache 入れた方がいいのかナー。 #article |