※ 修正が取り込まれた 2.2. 版以降であれば、言語設定に起因する変換失敗は発生しません。それ以前の版を利用する場合は、"LC_ALL=en_US.utf-8; export LC_ALL" 等により、言語設定を無効にしてください。 なお、convert エクステンションでは、内部処理が全て UTF-8 で実施されるため、HGENCODING やロケール設定で cp932 を指定しても、ファイル名の cp932 化はできません。 前回に引き続き、ロケール設定で日本語が選択されている場合の Mercurial と Subversion の連携における問題を調査。 @r_rudi 氏に情報採取をお願いしたところ、早速採取データの第一報が。 (snip) parsing revision 74 (11 changes) [DBG] subversion:_fetch_revisions: ..

※ 修正が取り込まれた 2.2. 版以降であれば、言語設定に起因する変換失敗は発生しません。それ以前の版を利用する場合は、"LC_ALL=en_US.utf-8; export LC_ALL" 等により、言語設定を無効にしてください。 なお、convert エクステンションでは、内部処理が全て UTF-8 で実施されるため、HGENCODING やロケール設定で cp932 を指定しても、ファイル名の cp932 化はできません。 話の発端は以下の tweet: tweet を見た時点で想定される原因としては、以下の要因によって、日付文字列形式が想定外になっているのであろう、というもの: (エラーメッセージが日本語なので) ロケール設定の影響 変換元形式のための python バインディングライブラリのバージョン差異 変換元リポジトリのサーバ側バージョンの差異 3つ目の要因の場合、クライア

最近、twitter 上で subversion 連携に関する質問に答えるために、convert エクステンション(標準同梱)とか、hgsubversion エクステンションのソースを確認しまくったので、折角だから Mercurial と Subversion の連携に関してまとめてみた。 結論から先に書いておくと、これまで twitter 上では: Mercurial ⇒ Subversion への成果反映が必要であれば、選択肢は hgsubversion エクステンションの一択 という回答をしていたのだけれど、色々考えてみるに: 『hg コマンド経由での svn リポジトリへの反映』に拘らなければ、実は convert エクステンションの方が便利じゃねぇ？ というのが現在の僕の印象。 但し、Mercurial の convert エクステンションは、認証処理周りの実装が無い。そのため、

Twitterでこんなことをつぶやいたら入門Mercurialの著者の方にいろいろ教えてもらいました。Twitterスゴイネ！ Twitterでのやりとり :left REVMAPとは http://mercurial.selenic.com/wiki/ConvertExtension REVMAP is a a simple text file that maps each source commit ID to the destination ID for each revision. Unless specified, it defaults to the .hg/shamap in the destination directory. This file is automatically created and updated on each commit copied, its

前置き hgsubversion自体の導入については↓をどうぞ hgsubversionの導入 - 文殊堂 ちょっと前までのhgsubversion ちょっと前までhgsubversionではsvnのリポジトリの完全なコピーを作ることしかできませんでした。 例えば10年物のsvnリポジトリをhg cloneすると10年分の履歴全てを取ってきてしまいます。 目的がsvnリポジトリのコンバートであるなら問題ありませんが、 svnリポジトリを正としつつMercurialの分散SCMの機能を活用して開発をいい感じにやりたい という場合には困ります。 git-svnのように特定リビジョン以降だけ持ってくるとかやりたいです。 startrev option で、changeset:827547493112から出来るようになりました。 残念ながら基底のURL(/trunk,/tags/,/branche

git-svnでリモートブランチをきって作業しててtrunkにmergeしようと思ったら、mergeした先のローカルブランチの向き先がリモートブランチになる現象ではまった。またしてもtypester++であります。インクリメントされすぎてそろそろ2147483647超えるんじゃないと心配です。 # 今masterブランチにいる $ git branch * master # リモートブランチはtrunkを見てる $ git svn info URL: http://path/to/trunk ... # リモートブランチtopicを作成してローカルブランチtopic_localにコピー $ git svn branch topic $ git checkout -b topic_local topic # ローカルブランチはtopic_local $ git branch master *

http://www.subversion.jp/index.php?option=com_content&view=article&id=50:subversion17enable-git-like-features&catid=25:subversion-article&Itemid=27 マジですか。TwitterでつぶやいたらTLがホットになったよw 次世代ワーキングコピー（Next Generation Working Copy (NG-WC)）というやつがキーらしい。 アナウンスの動画はこちら http://subversion.wandisco.com/component/content/article/1/41-whats-next-for-subversion.html 課題番号はこちら subversion: Issue 3357 仕様書はこちら http://svn.

ネットワークがつながらない状況での分散開発はどうやるのがいいかを考えてみる。 以前似たような経験したのは自分たちが複数の協力会社の１つという立場で、元請けのSVNリポジトリに直接コミットするというもの。ネットワークはつながっています。また元請けは基本的に開発はしておらず、協力会社も開発はほとんど終わっていて変更はバグ修正のみという状況です。 イメージはこんな感じ。 リリース（元請けのSVNリポジトリに直接コミット）する場合は、自分たちのSVNリポジトリにタグうってexportして、あらかじめチェックアウトしておいた元請けのSVNリポジトリのソースに上書きしてコミットします。この辺もHudsonで自動化してましたね。あとコミットするファイル一覧も出しました。元請けはそれと実際にコミットされたソースとを比較して漏れが無いか確認してたみたいです。 しかしこの方法だとファイルの削除やリネームに対応

夏休み突入しました。周りでは突入出来てない人もいるけど。。。--); ネットワークがつながらない状況での分散開発をマジにやりそうなので、それにそなえてHgSubversionを調べてみました。 開発者はSVNしか意識しないで、構成管理担当者がcloneして差分をbundleファイルでやりとりするのをイメージしてます。 svn diffのやり取りでもいけるかもしれませんが、まずはMercurialとSubversionの連携をやってみます。 試したOSはWindows Vistaです。 1.インストール Subversionは http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=11151&expandFolder=11151&folderID=91 からSetup-Subversion-1.6.6.msiをダ

もう8月ですね。暑いですね。W杯はスペインの優勝で幕を閉じました。 僕は7月からやばそうなプロジェクトに入りました。僕の7月の残業時間は60ですが、100オーバーの人も少なくないようです。夜中の11時過ぎても人がいっぱいいるのはやっぱ変ですよね。 来年の3月まで続くのにこの状況です。自分も含めて心身壊す人が出ないことを祈ります。 さてそんな状況ではありますが、興味深いエントリがありました。 分散型バージョン管理システムは実際の開発現場でどれだけ普及するか？ - 現場のためのソフトウェア開発プロセス - たかのり日記 エントリの内容には割と同意です。 僕自身も含めてですが、いままで見てきた感じでいうとSVNを使いこなしてかつ構成管理を意識できる開発者は多くないのが現実です。 ありがちなのはこんな感じ。 コミット漏れによるコンパイルエラー 他の人の変更内容を誤って上書き 自分が作業しているEc

hgsubversionではhg mergeしてできたmerge済みrevisionをpushすることはできない。 - wyukawa’s blogの続きですが、前回はhgsubversionではhg mergeしてできたmerge済みrevisionをpushすることはできないので、updateしてrevertしてcommitしました。 本家のページによると If there are new revisions, and you have new revisions in your local hg repository, this will create a new head. The important point to note is that hgsubversion cannot push merge changesets to a svn repository. This m

CodeRepos から GitHub に移行するパターンで，両方のレポジトリでユーザ名が同じでも，結局別人扱いされてしまうのでどうしたもんかなぁと思っていたのだけど，こことかこことか見るとマッピングファイルを作ればいいということがわかった． git help svn すると -A(--authors-file) というオプションがあって，これに次のフォーマットでマッピングを記述しておいて読ませるらしい． loginname = Joe User <[email protected]>loginname には svn での名前を書いておけばいい．行区切りで複数のマッピングを書ける． さらに svn.authorsfile という config にファイル指定しておけば良さげだったので，git config --global で登録してみた．これで git svn の度に -A しなくていい．

分散SCMを使いたい！と思う今日この頃。 仕事ではSVN（Subversion）を使っているのだが、ちょっとしたお試し編集をするためにブランチを作ることに抵抗がある。ブランチは欲しい、大きめな変更をコミット無しで行いたくない、やはり少しずつコミットして進めていきたい。しかし、変更が全て記録されてしまうのがいただけない。ログが残るのは良いことなのだが、本当に使うかどうか未知数な実験的プログラミングのログまで残したくない。使うと決まってから初めて残すようにしたいのだ。 すまん、これまで一緒に仕事をしてきた人々よ。俺はこれまで「ログが残って困ることがなんかある？いらなきゃ無視すればいいだけなんだから、気にするな。ブランチでもなんでもバンバン作ってしまえ！」とうそぶいてきているわけだが…ハッタリかましてました！本当は俺も抵抗があるのだ。 そこで、分散SCMだ。さらにいうと、SVKがいまひとつ気に入

前説 前回エントリは単純なmergeの例だったので、 svnリポジトリのbranchのmergeをMercurial上でやるメリットがそれほど大きくない。 Mercurialを使ってバージョン管理をする場合以下のようなやり方をすることが多い。 3のmergeでconflictがあまり発生しないのは、2.3でどのようにmergeしたか、 conflictをどのように解消したかをリポジトリが覚えていてくれるからで、 これをmerge trackingという。 branch作成 繰り返し branchで作業 defaultに変更発生(他branchからのmerge等) default→branchに逆方向merge branch→defaultにmerge 今回の話は、merge tracking機能がない1.4以前のsvnでもmerge tracking機能を活用して、 mergeを行う方法に

概略 hgsubversionではhg mergeしてできたmerge済みrevisionをpushすることはできない。 hg mergeしたら merge前revisionにhg update merge済みrevisionでrevert hg commit とやって同内容の非merge revisionを作ってそれをpushすれば良い。 せつめー 黄色のbranchから黒のdefaultにmergeするとする。 まず、TortoiseHGで普通にmergeする。 確認ダイアログでlocal:default,other:branchとなっているようにすること merge直後の状態はこのようになる。 hgsubversionではhg mergeしてできたmerge revisionをpushすることはできないので、 defaultのmerge直前revisionにhg updateし、 m

基本的にhttp://monkeyisland.pl/2009/11/04/hgsubversion-on-windows/を参考にする svnをインスコする hgsubversionを使うにあたってはsvnコマンドのインストールが必要。 TortoiseSVNが入っていてもダメ。 Apache Subversion 設定時に知っておくべきことか http://mino.blog.eonet.jp/minoproject/2009/08/windowssubversi.html Subversionのリポジトリをsvn+sshで管理する - Lism.in * blog - nekoya (id:studio-m) Mercurialをインスコする こちらはTortoiseHGを入れれば入るので、 好みに応じてTortoiseHGもしくはMercurial本体のみをインストールする。 Bi

つまみ食いとか青田買いといわれるcherrypickingはある特定のコミットをブランチから抜き出して別のブランチに反映させるというものです。 Subversion, Git, Mercuriaそれぞれのやり方を調べてみました。 まずSubversionいってみましょう。 準備 $ svnadmin create repos $ svn checkout file:///tmp/repos work Checked out revision 0. $ cd work/ $ svn mkdir tags branches trunk A tags A branches A trunk $ svn commit -m "add initial dir" Adding branches Adding tags Adding trunk Committed revision 1.trunkの直下に