作業スペースと集積スペース
いつも思うことだが、バックアップや世代管理を個人の作業に期待するのは愚策である。基本的にはそんなにマメに世代バックアップを用意するなんてばからしくやってられない。しかしだからと言って共同の作業スペース(Windows や Mac のファイル共有をイメージすれば分かりやすい)上のデータをすべて世代管理するなんて、膨大すぎて非現実的である。
「いわゆるコード」の場合、CVS で管理していれば working copy と repository は自動的に分離される。したがって repository そのものが爆発することは、まぁ運用ポリシーにもよるがそんなにないだろう。しかし repository と working copy が同居しやすい場合((例えば Zope や WebDAV 経由の Subversion なんかがそういう状態になりやすいだろう。実際には working copy と repository はイコールにはならないが、手軽なので「確認用の環境を用意しない運用になりやすい」んじゃないかと思う。))、リポジトリの爆発という問題とどうつきあうのかという、けっこう深刻な問題が発生する。
あ、cvs admin みたいにこの revision は必要ないから削除とか、そういう操作ができればいいのか?(もちろんすべてのファイルについてそんなことやっちゃいられないが。) Subversion は次世代のバージョン管理として期待値はでかいが、クライアント環境をあまり選ばない(CVS みたいに面倒なことを気にしなくてよい)分、repository の管理能力を問われそうな感じだな。あ、Zope + Subversion てのも手かな? 普段 Zope にどかどか突っ込んでいって、ちゃんとしたバージョンの段階で Subversion に突っ込んで publish、ZODB のサイズを見て不定期に pack を行う。あ、これいいかもしんない。
- Zope + CVS
- Subversion + CVS
- Zope + Subversion
- Subversion + Zope
なんかの組み合わせがなくはないのかな? とりあえず操作性や柔軟さを考えて CVS をフロントには置かないってことで。
More
Recent Posts
- » Bundler環境でIRBでもLSPでもドキュメントを利用する方法
- » Ruby 3.2と3.3のirb historyの扱いの違いと対処方法
- » Result型とRailway Oriented Programmingをめぐる旅
- » dry-operationのススメとエラー情報をViewまで持っていく方法の模索
- » aligach.netのRubyとViteをバージョンアップした
- » ViteRuby 3.7.0は起動方法のデフォルトがnpx経由になった
- » GmailからSpreadsheetとGoogle Driveへ書き出すGASライブラリを作った
- » 面倒くさがり屋のためのTypeScript環境
- » JavaScriptにも論理和代入なんてあったんだ
- » TypeScriptでpropertyを舐める処理が面倒くさい