昨年の ThinkPad 入滅が発端で、パソコンを３台所有することになってしまったのですが、ゲームの動作確認ができるようになりますので結果オーライかと思っておりました。ただ、こうなると過去の経験からして、メインのマシン１台のみを使うという事態になりかねません。自分の場合、ソフトウェアやメインの作業データが入っているマシンが１台だけというケースが多いためです。

ソースファイルでしたらバージョン管理ツールの管理下に入れてしまえば解決する話なのですが、これを思い切って他のファイルにも広げてみております。結果、リポジトリのサイズは大きくなりますが、いい感じで成功しているように思えます。

使っているソフトウェアの製品シリアルなどを保存した Excel ファイルもバージョン管理しているのですが、先日 XP マシンをリカバリする際に、別のマシンにてチェックアウトしたものを参照してインストールを完了させることができました。以前はテキストファイルに控えて USB メモリに入れたりしておりましたので手間を大幅に減らすことができております。

ただ、一応、バージョン管理ツールは最新版が手元にないと目的を達成できないファイルのみを管理下におくべきですので、このあたりの見極めが重要です。…といっても難しいことはありません。いらないファイルを管理下においてしまった場合は外すことができますので気軽に始めてみて良いと思います。

FenrirFS はバージョン管理から外れたファイルを管理するために使っております。主にメールの添付ファイルや仕事の作業過程データなどです（途中の計算に使った Excel ファイルなど）。これらのデータは前述のルールからするとバージョン管理下に入れない方が望ましいデータなのですが、いざという時にはすばやく目的のファイルを見つけられないと作業に支障をきたすことが多くあります（実際ありました）ので分類ツールが役立ちます。特に他人ルールにて命名されているファイルを抽出・検索するの際に強みを感じます。

新しいツールや手法に移行するというのはなかなか勇気がいるのですが、パソコンの不調と Vista 以降で安定して動作しないソフトウェアを使わなければならなくなった（つまり、 XP マシンを必要に応じて使い分けなければならなくなった）関係から従来のやり方を変えることになりました。

なんとかなるものです。

cl.exe を使う際、オプションを省略しまくると、可能な限りリンクまでして実行ファイルを作ってくれますが、これが不要な時は /c オプションを渡すとオブジェクトファイルを作って終了します。

cl.exe /c source.cpp

# 実行すると source.obj ができます
# たとえ source.cpp の中に main() 関数があろうがリンクされません

大きなプロジェクトを make などを使ってビルドする場合や、興味本位でオブジェクトファイルを解析したいときなど覚えておくと嬉しくなります。

なお、ソースコードを記述したファイルを「ソースファイル」と表現します。