チーム開発におけるバージョン管理の活用方法 − ＠IT（情報元のブックマーク数）
当然といえば当然なのだが、ActiveDirectoryでプロジェクトのセキュリティグループを作成してアクセス管理を一元管理したほうが良いだろうというお話。まぁ、当然といえば当然だが。。。なかなか開発系とシステム管理系って連携できないんだよね。
プロジェクト・リーダーや開発者など、プロジェクトのロールに対応するセキュリティ・グループ（Windowsネットワークがワークグループ構成の場合はローカル・グループ）を作成し、そのグループ・アカウントに対してアクセス許可設定を行うようにすることだ。
チーム開発におけるバージョン管理の活用方法（1/3） - ＠IT
VSSとかってデータベースが壊れることがあるんだ。へぇー。Subversionとかも、理科張りが必要なことが発生するらしいよ。ふーん。勉強不足だなぁ。使ったことないしｗ
最後に信頼性（ファイルが壊れてしまわないかなど）についても述べておく。信頼性は機能とは直接関係ないが、バージョン管理システムの根幹になる重要な要素である。この点、SQL Serverを利用するTFSは、そのほかのバージョン管理システムと比較して群を抜いて高いと思う。
チーム開発におけるバージョン管理の活用方法（2/3） - ＠IT
これは筆者の過去の経験からの話で、すべてのケースに当てはまるものではないことをあらかじめお断りしておくが、信頼性という点では、VSSははっきりいって論外である。私がかかわったVSSで開発していた過去のプロジェクトの半分以上で、データベースが壊れてしまったことがある。これは、サーバ・コンポーネントを持たず、クライアントから直接共有ファイルにアクセスするというアーキテクチャ上、やむを得ないことであるのは分かるが。
また、SubversionもTFSほど信頼性が高いとはいえない。筆者は過去、悪名高い（？）Berkeley DBを利用していたことがあって、そのおかげで何回かリカバリしなければならなかった。TFSでは過去に一度もリポジトリが破損したような事態は起きたことがない。
PMOという観点からも見ているあたりがすばらしい
開発チーム内のメンバーであれば当然それで問題はないのだが、複数の開発チームを束ねるPMO（プロジェクト・マネジメント・オフィス）といったチームから見ると、プロジェクト全体といった単位で状況を確認したいものである。逆にすべてを1つにまとめてしまうと、チェックイン・ポリシーやプロセス・ガイダンスなどの開発規則がすべてのチームに適用されてしまい、柔軟な対応がしづらくなってしまう。
チーム開発におけるバージョン管理の活用方法（3/3） - ＠IT
