過去ソフトウェアの共同開発などで良く使われていたバージョン管理システム。 複数のファイルのリビジョン(バージョン)を管理できる。 ちょっとした1つのファイルのリビジョン管理には RCS が便利。
作業ディレクトリ中の src ディレクトリ以下にタグ付け。
cvs tag -c release-1-0-0 src
作業ディレクトリ中の src ディレクトリ以下の間違えてつけてしまったタグを削除。
cvs tag -d release-1-0-0 src
cvs admin -mREV:MSG files
指定したリビジョンを消す(危険)。
cvs admin -oREV file
以前社外から社内 Web サイトへのアクセスは autossh + FoxyProxy を使って SOCKS 経由で直接できるように設定した (記事)。 また Unison や Subversion もそれぞれ SSH port forwarding 経由で直接アクセスできるようにしてある (Unison の記事、Subversion の記事)。
しかし社外から社内サーバへの SSH 接続(やファイル転送)は、以前として一旦中継ホストに接続(転送)してから再度接続(転送)していて面倒であった。
調べたところ Shun-ichi GOTO氏の SSH プロキシコマンド connect.c を使うと SOCKS サーバ経由で直接接続できるようなので設定してみた。
[クライアント:8090] -- SOCKS -- [ゲートウェイ] -- [社内サーバ] gw.example.com 192.168.1.x
Debian なので apt-get で。
apt-get install connect-proxy
~/.ssh/config に以下の行を追加。
Host 192.168.1.* ProxyCommand /usr/bin/connect-proxy -S localhost:8090 %h %p
192.168.1.* に接続する際は、connect-proxy を使ってローカルホストの 8090 ポートの SOCKS を通るようにする設定。
autossh を使って SSH で SOCKS サーバを立てる
autossh -N -f -D8090 gw.example.com
これで準備 OK。
ssh 192.168.1.x
で接続を確認。
fish://192.168.1.x/
で直接ブラウズ、読み書き可能なことを確認。
普通に 192.168.1.x と同期できることを確認。
普通に 192.168.1.x 上のリポジトリに対して cvs update できることを確認
普通に 192.168.1.x 上のリポジトリに対して svn update をかけるとアップデートし終わって最後に
FATAL: output (local) failed, errno=32
というエラーがでる。
Subversion だけちょっと気がかりだれど、その他はうまく行っている感じ。
これでかなり手軽に接続、転送できるようになった。 便利、便利。
一時的に connect.c を通らないで直接接続する際には 'ssh -o ProxyCommand=none' とする。
例: SVN_SSH='ssh -o ProxyCommand=none' svn update
分散型バージョン管理システムである Git では Subversion や CVS、Visual SourceSafe などと違って気軽にローカルリポジトリにコミットしていって、最終的に形になったところで公開/共用リポジトリに push するといったことができる。
こまめにローカルリポジトリにコミットしながら作業していくことで、いつでも後戻りしてやり直したり変更点を確認したりできる。ただちょっとした変更の連続によるたくさんのコミットを公開/共用リポジトリにそのまま push したくない。そういう場合は意味のある単位にコミットをまとめてから push したい。
Git では git-rebase でこれができる。
A---B---C---D---E | | | | | HEAD | HEAD^ HEAD~2
最初に git rebase する。
git rebase -i HEAD~2
すると
pick <HEAD~1のハッシュ> <HEAD~1 のログ> pick <HEADのハッシュ> <HEAD のログ>
という行を含む内容でエディタが起動する。HEAD を HEAD~1 にまとめたいので 2番目の pick を squash に書き換えエディタを閉じる。
すぐにまた今度はコミットログ修正のためのエディタが開く。HEAD~1 のコミットログと HEAD のコミットログがあらかじめ含まれているので、それらを編集して2つ分の内容を反映したものに書き換えエディタを閉じる。
これで直近の2つのコミットがまとめられて新しい1つのコミットになる。
A---B---C---F
ローカルでの試行錯誤をとりまとめて整理されたコミットになったのでここで push する。
git push
なお squash を使えばできるというヒントは @tokuhirom 氏に教えていただきました。ありがとうございます。
しばらく放置していたこの nDiki のコード(DiKicker)に手を入れようと思うのだけれど、CVS で管理し続けるのもなぁと思い、これを機会に Git に移行させることにした。移行は cvs2git で。ローカルで自分だけでバージョン管理していたものだし、ブランチも切ってなくてタグを売ってあるだけなので一番ちょろいケースか。
Debian GNU/Linux sid 上に cvs2svn Debian パッケージをインストール。以下の手順でコンバートした。
Git リポジトリ上できちんとユーザ名とメールアドレスが入るようにしたいため、オプションファイルを使うようにする。
zcat /usr/share/doc/cvs2svn/examples/cvs2git-example.options.gz > cvs2git.options
でひな型をコピーして以下を書き換え。
以下のコマンドで。
cvs2git --options=cvs2git.options
mkdir <プロジェクト名> cd <プロジェクト名> git init cat ../cvs2svn-tmp/git-blob.dat ../cvs2svn-tmp/git-dump.dat | git fast-import
で QGit や git log などで、どのようにインポートされたかを確認。trunk のラインから、タグ毎に分岐したコミットができてそこに CVSROOT/ 以下が差分として入っているという形になっているのが特徴的。CVSROOT/ は特にいらないので、数が多くないし手でタグ打ち直すかなあという感じ。
git fast-import したままだと作業ツリーが空なので git checkout して master を checkout するなりすれば、後は普通に Git 上でバージョン管理をしていくことができる。
あっさり移行できたので一安心。
2002年10月19日から開発を始めてしばらく公開・運用をしていた WikiEngine だけれど最近は WikiEngine そのものは使っていなくて、今はそのコードをベースに作った日記システム の DiKicker 部分しか使っていない。DiKicker の方は自分自身で今後も使っていくんだけれど、さすがにいろいろ古いのでそろそろ大改修しようかなと。基盤部分的には
などをして今後も使っていけるようにしたい。既に使っていないアプリケーションとしての WikiEngine 部分は移行させていく手間をかける必要はないと思うので、コードを削除していくことにした。WikiForum 立てるなら既にいろいろ他の選択肢があるしね。
CVS での管理もやめて Git 管理に変更。最後の公開 tarball を展開して git init して最初のコミットとし、その後に変更した作業ディレクトリを Git 側の作業ツリーに上乗せしていったんコミット。あらためて最後の公開コードの上に差分を積んでいくつもり。
2月の Developers Summit 2015 で zakwa 氏と再会したのをきっかけに、当時一緒に仕事をしていた気が置けないソフトウェア開発者4人で同窓会をすることになった。セッティングしてくれた zakwa 氏ありがとう!
手配してくれたお店は「焼きたてパンとワインのお店」COGS DINING KAGURAZAKA。神楽坂から路地に入ったところにあるお店で、上品な味の料理で満足だった。店内もうるさくなくて話しやすかったし、たばこを吸っている人もいなかったので快適だった。
現職のまま続けている1人と、別の場所で働くことになった3人だけれどみなそれぞれソフトウェア開発現場に関わっていて、それぞれの開発スタイルなどについて情報交換したり。
大企業だからしっかりした開発をしているとか、スタートアップだからモダンな開発をしているとかでは必ずしも無いよねという話だった。例えばバージョン管理一つにしてもうまくできていない(やっていない)場合も多いとのこと。当時を振り返ってみると小規模かつ独学の状況ながら、今では普通になってきたプラクティスやツールをその時から実践/活用していたなと自画自賛した。
「書けなくなったホワイトボードマーカーはその場で床に投げ捨て」に共感を持ってもらえていたのが、振り返って当時の自分の一番の成果だな。
退職時に使っていた社内 Wiki は Naney 謹製のものだったのでその後どうなったのかなとたまに気になっていたのだけれど、ビル管理会社の人に社内サーバの電源を切られたことによりサーバごと死んで闇に葬られたらしい。R.I.P.
同窓会らしく「あのひとは今」的な話をしたり、当時フィルムカメラで撮っていた業務風景のアルバムを持ってきて盛り上がったり。あとはレーシックやドライアイ治療ひぇー的な話題が出たり。あとは展示会の時のレクサー・リサーチポロシャツ制作秘話とか。
そういえば出席はできなかった2013年2月開催の「LEXER設立20周年記念サロン・パーティ」で会社のるぐるロゴの立体置物が配られたと聞いて、あ、欲しかったなーと。
先々週に Google ドライブ・Dropbox に同期しないファイルは Cloud Station に同期するように設定した。その際に Cloud Station の後継の Synology Drive が出ているのを知ったので、今日アップグレードすることにした。
公式サイトの手順に従いアップグレード。
サーバ側は問題なく終了。依存する Node.js が先立ってインストールされて「へー」ってなった。
Mac 側はちょっと大変な事態に。Synology Drive Client をインストールすることで Cloud Station Drive が置き換えられて同期設定も移行された。
問題はここから。移行後の初回同期で、変更が無いファイルも全てサーバからクライアント側にガンガン同期し始めた。これ、ファイル内容に変更はないのだけれど Time Machine 的には増分バックアップ対象になってしまって無駄なバックアップが作られることになった。
しかも一部ファイルが書き込めないとリトライし続けている様子。オーナーの書き込み権限がなかったファイル(CVS・RCS のファイルや過去 CD-R からコピーした psd ファイルなど)っぽい。
同期途中で一時的に「双方向同期」を「単方向アップロード」に変更してみた。アップロード方向だとローカルホスト上で更新がなければ転送しないようだ。
初回の同期が終わったところで「双方向同期」に設定を戻してみたところ、やはりまたダウンロードを始めてしまった。バックアップ目的でしか同期していないので「単方向アップロード」のままにしておくことにする。
そうそうメニューバーに表示される Synology Drive Client のアイコンがイケてないと思ったのだけれど設定から「シンプルなシステム トレイ アイコンを使うにする」にしたら単色のいい感じのなった。
「単方向アップロード」にした際に「ローカルで削除されたファイルをサーバーに保存」がオンになっていたのでオフに。
削除済みのものが NAS 側だけに残っているとわけが分からなくなるので一度「双方向同期」に変更したら、削除済みのファイルがローカルに戻ってきてちょっと辛いことになり始めたので中断。いったん同期タスクを削除 & NAS 側を削除し、あらためて双方向同期させた。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。