SVNのHEAD

今更ながら気づいたこと。SVNのクライアントにリビジョンとしてHEADを指定する際、headでも受け付けてくれる。

十数年間HEADとタイプし続けてきたけど、SHIFTを押さえていた小指は働き損だったのか…。

SVNでキーワード置換の文字数を制限する

職場のコーディングルールでヘッダに$Data$を入れないとならないのだけれど、文字化けがうざい。どうもShift-JISのテキストにもUTF-8で曜日(月〜金)が入れられているようなのだけれど、これはWindows版のクライアントの問題？ そもそも、今時Shift-JISなんて糞コードを使いたくないんだけど、これもルールなので自分ではどうにもならない。

で、どうにかならないかとググってみたところ、SVNのキーワード置換では、置換後の文字列の長さを制限できるとな。

$Date::                           $

のように書いておけば

$Date:: 2016-03-25 23:59:59 +0900#$

のように曜日(月〜金)が挿入される前に置換後文字列を打ち切ってもらえる。

休日出勤していないことをさりげなくアピールしてみたw

手元の作業コピーから.svnを除外してtar ballを作る

SVNのレポジトリにコミット済みのバージョンのtar ballを作りたければ、単純にsvn exportしたものをアーカイブするだけだ。が、未コミットな変更を含む手元の作業コピーを、ちょっと固めて渡したい場合はどうするか？ これまでは作業コピーのコピーを作ってから.svnを消して固めていたのだが、GNU tarには便利なオプションがあることに、今更気が付いた。

% tar zcvf foo.tar.gz --exclude-vcs working_copy

--exclude-vcsを付けるとバージョン管理システムのディレクトリを除外してくれるとのこと。ソースを見るとCVS, RCS, SCCS, SVN, git, Arch, Bazaar, Mercurial, darcsに対応しているようだ。

svn:externalsで外部参照の設定

SVNで

src
  +-- program1
  |     +-- (reference to common)
  +-- program2
  |     +-- (reference to common)
  +-- common

のように、SVN管理下の別のディレクトリを参照したい場合、参照を作りたいディレクトリのsvn:externals属性を編集する。

% cd src/program1
% svn propedit svn:externals .

でエディタを起動し、

../common common

と記述して

% svn update

すれば、program1の下にsrc/commonがチェックアウトされる。

参照先が同一レポジトリ内である必要はなく、

http://somewhere/trunk/common common

のように外部レポジトリでも指定可能。バージョン1.5より前はsvn:externals属性の書き方が違うので、いい加減に1.4とかを使うのはやめよう。

SVNで機械的に生成されるファイルの管理

Doxygen等で生成されるドキュメントをSVNレポジトリに突っ込んでおこうとすると、意外と面倒くさい。最初のコミットはまあいいのだが、2度目以降、再生成したドキュメントで更新しようと思うと、その都度ファイルの増減に対応しなければならない。

SVNはサブディレクトリ毎に管理情報を持っているので、何も考えずにサブディレクトリを丸ごと削除してから再生成するわけにも行かない。で、結局

1. 通常ファイルを全部消す
   Zshなら

   zsh% rm -f xx/**/*(.)

   こんな感じ。うっかり

   % find xx -type f -exec rm {} \;

   とかやると.svn/の中のファイルも削除対象になってしまうので、これは絶対NG。
2. 再生成
   DoxygenなりRDocなり、目的のツールを実行
3. 増えたファイルを追加登録
   svn statusで?印が付いているファイルをsvn add

   % svn add `svn status | gawk '/^\?/{print $2}'`

4. 減ったファイルを登録削除
   svn statusで!印が付いているファイルをsvn remove

   % svn remove `svn status | gawk '/^!/{print $2}'`

5. コミット
   

   % svn commit

全自動化は怖いので1ステップずつ目視確認しながらやってるんだが、めんどいね。どいね。レポジトリに置いておくのは生成ツールの設定ファイルと実行バッチくらいにして、機械的に生成できるものはレポジトリに置かないのが正解なんだろうけど、誰もが生成ツールをインストールしているとは限らないから、これまためんどいんだ。

また又・SVN使いだがGitに乗り換えようと思う

レポジトリ間の連携の話。
今回は分散型ならではの話なので、Subversionとはの比較は無し。

まずは既存のレポジトリをgit cloneで複製して、各々が自分専用のレポジトリを作成する。

複製の複製も可能。

他のレポジトリの変更を自分のレポジトリにマージするにはgit pull。自分のレポジトリの変更を他のレポジトリにマージするにはgit push。

ただ、他のレポジトリを変更するgit pushは、そもそも許可されているとは限らない。そんなときはレポジトリの持ち主にpullしてもらう。
なお、pull/pushで変更するのはレポジトリ全体ではなくブランチ。

他のレポジトリのエイリアスを登録しておくと、操作の度にURLを入力しなくても済む。エイリアスの追加や削除等は、git remoteで管理できる。なお、git cloneで複製したレポジトリには、デフォルトで複製元のレポジトリにoriginという名前が付けられている。

続続・SVN使いだがGitに乗り換えようと思う

GitのブランチがSubversionのそれと違うなぁと思った点を3つ。

まず実装。そもそもSubversionのブランチは、運用でブランチとして扱っているだけの単なるサブディレクトリなので、明確にブランチ機能を備えたGitとはまるで違う。

次にブランチ作成の気軽さ。Subversionでブランチを作るということは、共有レポジトリに新たなサブディレクトリを作るということ。運用ルールにもよるけれど、ちょっとした実験用ブランチを作るのは気が引けてしまうことも多い。一方Gitなら、あくまで自分専用のレポジトリなので、実に気軽にブランチを作成できる。

最後にマージの厳格さ。コミットもブランチ作成も気軽なGitだけれど、マージに関してはSubversionよりGitの方が細かい。Subversionの場合、どの変更をマージしたかという情報(mergeinfo)が欠落している場合が結構ある。…というか、mergeコマンドを使わない(人|クライアント)が結構多い気がする。mergeinfo自体が後付けなので仕方ない気もするけれど、理由はどうあれ、何をマージしたのか分からなくなるのは非常に困る。
一方Gitは、マージも含めて適用してきた変更をきちんと把握しているので、mergeコマンドでは未適用の変更のみを正確に適用できる。もちろんGitでも、mergeコマンドを使わずに出所不明の変更としてcommitすることはできるけれど、そこは分散型の良いところ。自分専用のレポジトリなのだから、きちんとマージするというルールを自分だけが守っていれば、他人のいい加減なマージに振り回されることは無い。

他人のレポジトリと同期する話は後ほど。

続・SVN使いだがGitに乗り換えようと思う

超基本的な変更〜コミットの操作を比較してみよう。
まずはSubversion。

単純に作業コピーを変更したら、svn commitで変更をレポジトリに反映させる。commitする前であれば、svn revertで元に戻せる。

次にGit。

Gitの場合、単に変更しただけのファイルはコミット対象にならない。基本的には、明示的にgit addで変更内容を登録してから、git commitで登録しておいた変更内容をレポジトリに反映させる。まあ、面倒ならgit commit -aでaddしながらcommitもできるけど。
さて、注目すべきはgit resetで過去のバージョンへ戻れる点。Gitではcommitそのものを取り消すことが出来る。どうせ自分専用レポジトリだし、最悪でも取り消せるので、気軽にcommitできることが大きな特長のひとつとも言える。恥ずかしいtypoがずっと残ってしまうSubversionとは実に対照的。

しかし、改めて図示してみると複雑だなぁ。まだブランチも出て来てないのに。

SVN使いだがGitに乗り換えようと思う

SubversionからGitに乗り換えようとしているのだが、その過程をつらつら書いてみる。
まず、軽く使ってみてSubversionと違うと感じたことと、似てると思ったこと。

Subversionと最も異なる点は、何と言ってもGitが分散型であること。
Subversionでは、ある時点でのレポジトリの内容を手元に複製して作業をするのに対して、Gitではレポジトリそのものを手元に複製して作業する。これによって嬉しい点は

1. レポジトリの操作が速い
2. ネットワークに繋がっていなくてもレポジトリを操作できる
3. 気軽にレポジトリを変更できる

こんなところ。1と2は単純に手元にレポジトリがあるが故。分散型ならではの最大のメリットは、やはり3。Subversionは皆で1つの共通レポジトリ突っつくので、例え自分のブランチであっても、あまりいい加減なコミットはためらわれる。また、ブランチの粗製濫造にも抵抗がある。一方、手元に複製してきた自分専用のGitレポジトリなら、どんな駄コミットでも気軽にできるし、実験的なブランチも気兼ねなく作成できる。

バージョンの振られ方は似ているかな。どちらもコミットの単位は、レポジトリに対する何かしらの変更。レポジトリへの変更をコミットすると、全体のバージョンが進む感じ。まあ、細かいことを言えば異なる点は多々あるけれど、どちらもCVSのようにファイル毎に別々にバージョン管理しているわけではない。

実践的な話は明日以降に。

Subversionで作業コピー中のディレクトリのリネーム

チェックアウトした作業ディレクトリの中に、新たなSVN管理下のディレクトリfooを作る。

% svn mkdir foo
% svn commit -m ‘made foo’

次に、新たなディレクトリfooの中に新たなファイルをfoo.txt追加する。

% echo foo > foo/foo.txt
% svn add foo/foo.txt
% svn commit -m created foo.txt’

この状態で、作業コピーの中のfooをbarにリネーム。

% svn mv foo bar

そして、このリネームをコミットしようとすると…

% svn commit -m renamed
svn: Commit failed (details follow):
svn: Directory ‘xx/foo’ is out of date

怒られる。怒られてコミットできない。

結論から言うと、mvする前にupdateしておけば怒られない。
まず、コミットできなかったリネームは無かったことにしてから、アップデート。

% svn revert -R foo bar
% rm -fr bar
% svn update

それから再びリネーム。

% svn mv foo bar
% svn commit -m renamed

今度は通る。

要するに、何となくupdateしたら何とかなったのだけれど、そもそも駄目だった訳を理解していない。mvではなくcpなら問題は起こらないので、移動元の指定がおかしいことは無いと思うんだが…。
とりあえず対処療法的にupdateするか、mvするときはレポジトリのURLを指定しよう。