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