« 2010年11月 | トップページ | 2011年1月 »

2010年12月の3件の投稿

2010/12/21

ExcelをBazaarで管理する場合はTortoiseBZRをインストールしない/むやみにbzr statusを実行しない

追記:本エントリの記載はいくつか勘違いを含んでいました。TortoiseBZRメンテナのmethaneさんから補足頂いていたり、勘違いの修正も記載していますのでコメント欄も参照ください

 

前回の、Excelファイル(.xls)をBazaarでバージョン管理すると、保存しなくてもファイルを開いて閉じるだけで編集状態になってしまう問題の原因と思しきものと対処方法がわかりました。

確認したのは現時点でのWindows版(Standalone)最新バージョン、2.2.1-3です。

 

原因

周知の通り、編集可能なExcelファイル(拡張子が.xlsの形式のもの)は、開いただけでファイルが変更されます。ただし変更しないで閉じると元の状態に戻るため、通常(Subversionなど)は変更したとはみなしません。

bzrの場合、バイナリファイルについては、一旦modified(変更状態)であると認識すると、元の状態に戻ってもmodifiedのままになるようです。つまり、

  1. Excelファイルを開く
  2. bzr statusコマンドを実行する ←ここでmodifiedとなる
  3. Excelファイルを閉じる(保存しない)

という操作を行うとファイルが変更されたとみなされてしまうようです。svnの場合は、2.でsvn statusの時点ではmodifiedとなりますが、ファイルを閉じた後は再び変更なしに戻ります。

そんな状態でbzr statusを実行しなければ良いだけじゃないのか、と思うかもしれません。しかし、tortoiseBZRをインストールしていたりBazaar Exploerを起動していたりすると、明示的にbzr statusコマンドを実行せずとも、何かのタイミングでstatusコマンド相当が実行されるようで(アイコンオーバレイの更新とか?)、いつの間にかmodifiedになっていた、ということが頻繁に起こりました。

 

対策

その1。Excelは.xlsフォーマットでなく.xlsxフォーマットで扱う。

根本的な原因は、編集していないにもかかわらずファイルを変更してしまうExcelが悪いと言えます。.xlsxフォーマットではそのような行儀の悪い動作は起こらないようなので、こちらを用いるのが正しい対策だと言えるでしょう。ただし、bzrと相性が悪いから.xlsxに変更します、とすぐ対処できるような環境なら、そもそも初めから.xlsなんて使っていないと思われますのでこの対処は難しいのではないでしょうか。

その2。tortoiseBZRやBazaar Explorerをインストールしない。

自分の意図しないところでstatusコマンドを実行されなければ、予期せず編集状態にしてしまう機会も減少させられるでしょう。tortoiseBZRをインストールすると自動起動するtbzrcache.exeプロセスはツールバーから終了させることができるのですが、bzrコマンドを実行するとまた勝手に起動するようなので(これ仕様なのですかね?バグじゃないのかな…仕様でした)、初めからインストールしない方が事故が防げると思います。

ちなみに、bzr statusを実行しなければ良いように書いてきましたが、おそらくbzr commitなど他のコマンドでもファイル変更確認走査は実行されているはずなので、管理対象のExcelを開いている場合には、bzrコマンドは実行しない、という風に決めておいた方が楽だと思います。

 

さて、SVNとの連携(bzr-svn)ですが、svn+httpsは指定できない、とか、checkoutはできるがcommitできない、とか書かれているページがあったのですが、現在のバージョンではcommitも問題なくできているように見え、考えていたことは実現できそうです。

Excelの差分確認はこちらで公開されている「Windowsで外部コマンドが起動できないバグを修正するプラグイン」「extdiffplusプラグイン」の2つを利用して実現することができています。

2010/12/15

BazaarでExcelファイルをバージョン管理しようとしたがうまくいかなかった

 

前回に続いてバージョン管理の話題になります。

svn上のブランチをとある理由で切れない理由があり、しかし比較的多数のバージョン管理対象となっているファイル(.xls)を変更する必要ができたので、分散バージョン管理システム(DVCS)でローカルリポジトリを作成し、一時的にそこへコミットしておこうとしてbzrを利用しようとしたのですが、2点はまりました…

1点目。WindowsXP(32bit)環境だったのですが、この環境でbzrコマンドを叩くと(initだろうがcommitだろうが)かなりレスポンスが悪く、さらに高頻度で下記のようなエラーが発生する事態になりました。

bzr: ERROR: exceptions.UnboundLocalError: local variable 'lock_url' referenced before assignment

Traceback (most recent call last):
  File "bzrlib\commands.pyo", line 912, in exception_to_return_code
  File "bzrlib\commands.pyo", line 1112, in run_bzr
  File "bzrlib\commands.pyo", line 690, in run_argv_aliases
  File "bzrlib\commands.pyo", line 705, in run
  File "bzrlib\cleanup.pyo", line 135, in run_simple
  File "bzrlib\cleanup.pyo", line 165, in _do_with_cleanups
  File "bzrlib\builtins.pyo", line 1833, in run
  File "bzrlib\bzrdir.pyo", line 1726, in create_repository
  File "bzrlib\repofmt\pack_repo.pyo", line 2560, in initialize
  File "bzrlib\repository.pyo", line 3254, in _upload_blank_content
  File "bzrlib\lockable_files.pyo", line 187, in lock_write
  File "bzrlib\lockdir.pyo", line 648, in lock_write
  File "bzrlib\lockdir.pyo", line 616, in wait_lock
UnboundLocalError: local variable 'lock_url' referenced before assignment

bzr 2.2.1 on python 2.6.4 (Windows-XP-5.1.2600-SP3)
arguments: ['bzr', 'init-repo', 'repo']
encoding: 'cp932', fsenc: 'mbcs', lang: None
plugins:
  bzrtools             C:\bin\Bazaar\plugins\bzrtools [2.2.0]
  colo                 C:\bin\Bazaar\plugins\colo [0.1.0]
  explorer             C:\bin\Bazaar\plugins\explorer [1.1.1]
  fastimport           C:\bin\Bazaar\plugins\fastimport [0.9.0dev]
  launchpad            C:\bin\Bazaar\plugins\launchpad [2.2.1]
  loom                 C:\bin\Bazaar\plugins\loom [2.2.1dev]
  netrc_credential_store C:\bin\Bazaar\plugins\netrc_credential_store [2.2.1]
  news_merge           C:\bin\Bazaar\plugins\news_merge [2.2.1]
  pipeline             C:\bin\Bazaar\plugins\pipeline [unknown]
  qbzr                 C:\bin\Bazaar\plugins\qbzr [0.19.2]
  rewrite              C:\bin\Bazaar\plugins\rewrite [0.6.1]
  svn                  C:\bin\Bazaar\plugins\svn [1.0.4]
  upload               C:\bin\Bazaar\plugins\upload [1.0.0dev]
  xmloutput            C:\bin\Bazaar\plugins\xmloutput [0.8.6]

*** Bazaar has encountered an internal error.  This probably indicates a
    bug in Bazaar.  You can help us fix it by filing a bug report at
        https://bugs.launchpad.net/bzr/+filebug
    including this traceback and a description of the problem.

原因としては、ウイルスバスター2010が悪さをしていたようで、ウイルスバスターのディレクトリ除外設定で、ローカルリポジトリを作成しようとしている場所を監視対象から外すことで解消しました。なお、Windows7(64bit)とウイルスバスター2011の環境でも試してみましたが、こちらでは発生しませんでした。

 

2点目。冒頭に記載した通り、Excelファイル(.xls)を対象にバージョン管理したかったのですが、なぜかファイルを開いて閉じるだけ(保存しない)で、ファイルに変更が発生したという状態になってしまい、どれが本来commitされるべきものなのかわからなくなる事態が発生しました。svnで管理している同じファイルを開いて閉じて、と試してみたのですが、svnでは変更有りとはみなされませんでした。変更判定の基準が違うのでしょうか…?

検索してみたところ、未解消のバグとしてBug #113823 bzr status still shows MS Excel file as 'modified' after commit というものがありました。こちらではファイルに全く触っていなくても変更有りとなってしまっているようですね。ただ先ほどと同様のWindows7x64環境では、#16で報告されている事象は発生しないようで、何か環境に依存しているのかもしれませんね。

2点目については結局解消方法がわからず、今回bzrを利用するのは断念することにしました。

他のDVCSはWindowsへの導入が面倒だったり、日本語ファイル名の扱いが微妙だったりするようなので、どうしたものかと…

2010/12/12

svn revertするとファイルが消えてしまった

よく分からなくなってもsvn updateとsvn revertやればどんな状態からでも復帰できるだろう、と考えてる私みたいな人だとはまってしまうと思いますので、知識として頭の片隅に置いておくと良いかと思います。

Subversion1.6よりtree conflict機能が追加されたそうですが、これとatomic replace機能が競合している気がします。

試したのはTortoiseSVN1.6.12とSilkSVN1.6.13ですが、1.6以降であればどのクライアントでも発生すると思います。

 

手順

2人のユーザ(A,B)が同じファイルをそれぞれのワーキングコピーで編集している想定です。

  1. ユーザAが自分のワーキングコピーでファイル”file.txt”を削除します。(svn delete file.txt)
  2. その後、ユーザAはcommitを行わずに同名ファイルを追加します。(svn add file.txt)
  3. ユーザAは上記をコミットします。(svn commit file.txt)
  4. 一方、ユーザBは自分のワーキングコピーでfile.txtを編集します。
  5. その後、commit前に更新を行おうとします(svn update)

3.でユーザAがcommitを行うと、ファイルの状態はreplace(置換)になります。

5.でユーザBが更新しようとしたファイルはもうリポジトリには存在しないので(リポジトリにあるのは同名の別ファイル)、tree conflict(ツリー競合)になります。

こういう状況で、ユーザBはとりあえずリポジトリの状態と同期させようとsvn revertすると、file.txtがバージョン管理対象外になってしまいます。

この状況になると、TortoiseSVNやEclipseプラグインなど、GUIで操作するクライアントからはfile.txtを救出することができないようです。

 

復旧策

コマンドラインから実行できる場合は、svn update file.txt とファイル名を明示的に指定してupdateすれば回復します。ファイル名を明示せずsvn updateだけでは駄目です。

コマンドラインでの実行が行えず、ファイル名を直接指定できない場合には親ディレクトリを一旦削除し、その後そのディレクトリをsvn updateしてやれば、file.txtを含めて取得できます。

 

どういう操作をすればこんなことになるのか(普通わざわざsvn delete,svn addなんてやらないだろ)、と悩んだのですが、もしかするとEclipseなどのIDE上でファイルを削除すると、自動でsvn deleteが発行されるのかもしれません。その後別の場所で作成しておいたファイルを、modifyのつもりでcommitするとreplaceになる、と。このときaddもIDEからは明示的に行わずに済むのでしょう。[追記: こちら方の記述を見ると、やはりIDE上のファイル操作とVCS操作は連動しているようですね。 EclipseでSVNコミットしたら履歴が消えた。 - 戦う葦 ~ウェブリテラシー篇]

少数のファイルを対象にしている際には気付くと思うのですが、svn switchなど大量のファイルを一気に更新する際には見逃す可能性が高く、ハマることもあったので注意です。

 

後で気づいたのですが、上記の現象はtree conflicts with replaceで議論されていたようで、ITSへは3334:Tree conflict merry-go-round on update/switchで登録されているようです。1年以上前に報告されていてまだ解消されていないということは、根が深いのでしょうかね…?[追記 2011/7/21: 上記レポートに追記されている通り、1.7.0で解消されるようです。]

 

後で読む用リンク:

検索するとStefan Sperlingという方の名前がよく出てきますが、この方がSubversionのtree conflict検出実装をされた方なんでしょうかね。

« 2010年11月 | トップページ | 2011年1月 »

other sites

  • follow us in feedly
  • github
  • stackoverflow

ソフトウェアエンジニアとして影響を受けた書籍

  • Christain Bauer: HIBERNATE イン アクション

    Christain Bauer: HIBERNATE イン アクション
    理論と実践が双方とも素晴らしい製品であるHibernate。本書はそのプロダクトを書名に冠していますが、Hibernateを使うつもりがなく、ORマッピングの解説書として読むにしても十分な良書です。Second EditionとしてJava Persistence With Hibernateという書籍も出版されていますが、残念ながら現在のところ 和訳はされていません。-インアクションは2.xの、Java Persistence-は3.1の頃のものなので、最新版とはちょっと違うところもあることに注意。 (★★★★★)

  • アンドリュー・S・タネンバウム: 分散システム 原理とパラダイム 第2版

    アンドリュー・S・タネンバウム: 分散システム 原理とパラダイム 第2版
    クライアント/サーバシステムを構築する上で必要となる知識が総論されてます。Web技術者も、フレームワーク部分を開発するのであれば必読。 (★★★★★)

  • Joel Spolsky∥著: ジョエル・オン・ソフトウェア

    Joel Spolsky∥著: ジョエル・オン・ソフトウェア
    前述の書籍「ソフトウエア開発プロフェッショナル」をより砕いたもの、という感じでしょうか。 前書きではプログラマでなくSE向けの本のように書かれているが、プログラマが読んでも面白い本であると思われます。 SEになった新人(あるいはそういう会社に入る/入りたての人)にとっては、これからどういったことが仕事を遂行していく上で起こりえるのか、どのように考えて行なっていけばいいのか決定する助けになると思います。 元は″Joel on Software″というブログの記事で、web上でも一部日本語で読めます。 http://japanese.joelonsoftware.com/ (★★★)

  • ドナルド・C・ゴース,ジェラルド・M・ワインバーグ: ライト、ついてますか

    ドナルド・C・ゴース,ジェラルド・M・ワインバーグ: ライト、ついてますか
    問題解決(一昔前のの流行語で言うところの『ソリューション』)能力は、システムエンジニアのスキルとして備えるべきもののうちのひとつです。しかし、これは難しい。学校で出されるテストと違い、唯一の、(問題提出者が想定している)解を求めるだけが「問題解決」では無いからです。そもそも、何が問題なのか、それは本当に問題なのか、それは本当に解決すべき問題なのか、その問題解決方法は正しいのか、などを解決しなければ、「その解は正しいのか」に辿りつくことができません。この本の最も良いところのひとつは、本があまり厚くないこと。すぐに読めるし、何回も読み返す気になるでしょう。 (★★★★★)

  • スティーブ・マコネル: ソフトウエア開発プロフェッショナル

    スティーブ・マコネル: ソフトウエア開発プロフェッショナル
    コードコンプリートで有名なスティーブマコネルの著書。新人SEに読んで欲しい。個人として業界の中でどうあるべきか、組織としてどうあるべきか、SEのプロ意識とは?SEの心構え概論、といったところでしょうか。また、業界における資格の重要性についても説かれています。この業界では資格が特に軽んじられる傾向がありますが、この傾向はどんな弊害をもたらすのか、将来的にこの業界は資格に対してどのような姿勢で臨んでいくべきなのか。日経BP社では(他の出版社もだが)最近、似たような類いのあまり面白くない書籍が乱出版されていますが、この本は別格だと思うので安心して購入して欲しいと思います。 (★★★★★)

無料ブログはココログ