VisualSourceSafe6.0dの調子がおかしい。

なんだか、VSSサーバとの整合性がとれなくなってしまいました。まぁ、今現在開発をおこなっているクライアントは一台だけなので、最新のソースコードがとれなくなったという重大な危機に直面している訳ではないのですが、VSSが使えないのは結構困る為、VSS_DBの再作成をおこなうことにしました。
現行のVSS_DBを削除するため過去のソースコードの履歴等も削除される事になるのですが、そんなに規模の大きな開発じゃない＆やっているのはワタシだけという状況なので気にせず大掃除。過去のソースコードから復旧なんて、ここ最近やってないし。*1
験を担ぐ意味も含めて、一度全てを削除してからプロジェクトフォルダのみを抜き出すという形に。プロジェクトフォルダを「scc」で検索してVSS関連のファイルをすべて削除。これで、とりあえずはVSSに縛られないプロジェクトができます。*2これをプロジェクト分繰り返します。これが下準備。
次に、新しくソリューションを作成。作成が完了したら、バックアップしたプロジェクトを追加する前にVSSにソリューションを追加。ちなみにVSS6dからは、hogehogeSolution.rootというフォルダがVSSに自動的に追加され、ソリューションはそのrootフォルダの子供になります。*3それが終わったらば、片っ端から既存のプロジェクトを追加。それが終わったらまとめてVSSに反映。これで終わり。
前述したようにVSS6dからソリューションルートというのが加わった為、Webプロジェクトはソリューションフォルダの配下ではなく、ソリューションルートの配下に加わります。じぶんは、ソリューションフォルダの下にWebプロジェクトを追加していたので*4、ソリューションルートは逆にいらなかったりもしますが、まぁ実害はないのでそのままで。ソリューションフォルダの配下じゃないところにフォルダがあるというのは、妙な違和感があったりもするのですが。VSS6dでソリューション全体の管理をVSSが肩代わりしてくれるので、殆どVSSを意識せずにプロジェクトの追加等ができるようになったのは楽です。でもその分、自由度が無くなったのは確か。やっぱり、Webプロジェクトはwwwroot配下に置くべきなのかなぁ。

*1:そういうことしてっと、あとから痛い目をみるんだよなぁ

*2:嘘です。本当は他のファイルに「このプロジェクトはVSSで管理されているよん」という情報があるので、プロジェクトを開くときにエラーがでます。でも重要なエラーじゃないしもう一度VSSに参加すれば消えるので無視。本来であれば、プロジェクトのコピーのほうがいいのかも…。

*3:詳しくは＠ITのhttp://www.atmarkit.co.jp/fdotnet/teamdev/teamdev07/teamdev07_02.htmlで。

*4:wwwrootではなく、VSSのフォルダ構成と合わせるために