ザリガニが見ていた...。ザリガニが見ていた...。読者になるザリガニが見ていた...。この広告は、90日以上更新していないブログに表示しています。2012-10-19バージョンをGit的な視点で観察してみるmachello.txtでオートセーブやバージョンの仕組みを調べているときに、面白い仕様を発見した。あるとき、hello.txtをリッチテキストで保存してしまった。(テキストエディットは、command-shift-Tのショートカットで素早くリッチテキストに切り替えられる!)リッチテキストにすると、ファイル名の拡張子がhello.rtfに変化する。Leopardまでは「hello.txt」に加えてもう一つ「hello.rtf」ファイルが新規作成される。Lionでもそのようにファイルが追加されると考えていた。ところが、現実は違った...。デスクトップから「hello.txt」は消えてしまった。いや、「hello.txt」のファイル名が変更され「hello.rtf」として保存されたのだ!編集中のファイル名の変更は「別名で保存」されるのではない。今開いているファイルの名前を変更することになるのだ。バージョン履歴はどうなるのだろう?hello.rtfに変更すると、hello.txtのバージョン履歴が見えなくなってしまうのではないか?そんな不安がよぎったが、それは無用な心配だった。hello.txt世代からのファイルを追跡してくれている!(素晴らしい!)そしてこの仕組みは、一貫している。名称変更...でファイル名を変更しても、バージョンブラウザは追跡してくれた。編集中にFinderでファイル名を変更しても大丈夫。バージョンブラウザは追跡してくれた。移動...でファイルの位置を変更しても、バージョンブラウザは追跡してくれた。編集中にFinderでファイルを移動しても大丈夫。バージョンブラウザは追跡してくれた。!こんな仕組みになっていたのか、という閃きがあった。別名で保存...」と組み合わせることで、これはもしやGitなどのバージョン管理システムで言うところの「タグ」や「ブランチ」を実現できるのではないか?と思い始めたのであった。ちなみに「複製」と「別名で保存...」の違いや仕組みは以下のようになる。現在の書類をコピーして、名称未設定な新規書類を作成する。元の「hello_world.rtf」ウィンドウを残しつつ、「名称未設定(hello_world.rtfのコピー)」ウィンドウが開かれる。(2つのウィンドウが表示されている状態)まだファイル名を指定せず、保存していない状態である。現在の書類をコピーして、別のファイル名で保存する。元の「hello_world.rtf」ウィンドウは、別名で指定した名称のウィンドウに置き換わる。(1つのウィンドウが表示されている状態)すでにファイル名を指定して、保存している状態である。「複製」や「別名で保存...」で作成された書類は、どちらも元の書類のバージョン履歴には影響を与えない。「複製」や「別名で保存...」された時点から、新たなバージョン履歴が始まる。タグやコメントを付けるもはやバージョンでは、ファイル名がどのように変化しても、決して見失うことなく追跡してくれることが分かった。「名称変更...」を大いに活用して、ファイル名にコメントやタグの情報まで含めてしまえば良いのではないかと。ファイル名がすべて同じでは、一体どのバージョンに戻ったら良いのか悩んでしまうこと必至である。タグやコメントを「名称変更...」で削除して純粋なファイル名に戻す。以上のように運用しておけば、最終的にFinderから見えるのは、純粋なファイル名だけにできる。書類のどこかに何か1文字追加して、すぐ削除すれば、書類は「編集済み」の状態になる。保存(command-S)」することでバージョン履歴に何度でも追加できる。以上の方法で、タグやコメントは、思い立った時にいつでもバージョン履歴に追加できるのだ!ブランチを作るブランチは「複製」または「別名で保存...」することで実現できる。ブランチ名は、タグやコメント同様、ファイル名に含めておく。ブランチはバージョン履歴として継続していくので、タグやコメントとは区別した位置に書き込んだ方が良さそう。例:(コメントのテキスト)ブランチ|hello_world.rtfあるいは、ブランチ名のフォルダを作って、そのフォルダに保存するようにしても良いかもしれない。フォルダ方式なら、ファイル名に余分なブランチ名を追加しなくてもいい。実際に、バージョン管理システムであるSubversionは、この方式でブランチを作るのだ。その他のGit的な視点バージョンでは、作業ファイル・インデックスの明確な区別はできないが...ファイルが「編集済み」の状態でオートセーブされるのは、Gitで作業ファイルに保存する感覚に近い。add(インデックスに追加)する感覚に近い。commit(コミット)される感覚に近い。-a(インデックスに追加&コミット)する感覚に近い。バージョンのバージョン履歴は、Gitでは.gitフォルダ内のリポジトリである。監査などで指摘があると、ちょっとした修正の財務諸表を複数作る羽目になる。ファイルはたくさんあっても、過去のファイルを使うことはほとんどない。そのような場合は「タグ」や「コメント」を付けて、1ファイルのバージョン履歴で管理した方がスッキリして良さそうな気がする。契約書などの履歴管理は、「タグ」や「コメント」でバージョン管理しておくと良さそう。企画書を提出したら、2つのケースに分けた案にして欲しい、と要望されてしまった。2つの案は、その後の会議で何度も修正していく可能性がある。修正が繰り返される可能性があるのなら、「ブランチ」方式で2つのファイルに区別して管理した方が良さそうな気がする。これ以上の使い方がしたくなったら...マージしたい。