hg revert しても ステータスが modified から変わらないのですが…
Shinobu Koyama
フジワラ
On 7月30日, 午後9:57, Shinobu Koyama <y015h1...@gmail.com> wrote:
> ローカルリポジトリで作業中、ファイルに加えた変更を破棄するために hg revert したのですが、
> 状態が modified から変わらず、hg st で M と表示されます。
>
> 当方環境
> ・OS : Windows Vista 32bit SP1
> ・Mercurial : TortoiseHg 2.1.1
> ・セントラルリポジトリに bitbucket を使用
> ・5名でセントラルリポジトリを介して作業
> ・Windows, Mac 混在環境
> ・当方リポジトリのパスには全角文字は含まれていません。
- ローカルリポジトリ A で、あるファイルが modified 状態
- hg diff 出力は:
- ファイルモードの改変は無し
- １行の差異が出力されるが、見た目は同一
- 一番怪しいのは改行コードだが "hg revert" や "rm + hg update" しても改善なし
- "hg update null + hg update tip" しても、modified 状態は変わらず
- 別なリポジトリ B を clone すると、そちらは clean
- A と B のファイルの差分を取ると、先だっての hg diff よりも多い差分が出力
という感じで、一見リポジトリ A が壊れているっぽい感じがするのですが、
clone した B が正常ということを考えると、ちょっと辻褄が合わないなぁ、
という印象でした。
＃ DOS 窓 + cygwin 無しだったので、od 比較とか外部 diff 実行は出来てません
> 【経緯】
> 7/30にOracle青山センターで行われたSCM BootCamp にて Mercurial を初めて使いました。
> 常識外れの使い方をした可能性もあるかもしれません…
> その席にいらっしゃった方（お名前を聞きそびれました…申し訳ありません）からローカルにある
> ファイルを全てこちらに送って下さいとお願いされたのですが、
twitter タイムラインに ML メンバーの見慣れたアイコンがチラホラと散見（笑）されたので、
挨拶がてら寄らせてもらいました。
> MLにいきなり送りつけてもよいでしょうか？
> # zip で 20KB
KOIE Hidetaka
Date: Sat, 30 Jul 2011 21:57:43 +0900
From: Shinobu Koyama <y015...@gmail.com>
Subject: [mercurial-ja:565] hg revert しても ステータスが modifie..
| ローカルリポジトリで作業中、ファイルに加えた変更を破棄するために hg revert したのですが、
| 状態が modified から変わらず、hg st で M と表示されます。
|
| 当方環境
| ・OS : Windows Vista 32bit SP1
| ・Mercurial : TortoiseHg 2.1.1
| ・セントラルリポジトリに bitbucket を使用
| ・5名でセントラルリポジトリを介して作業
| ・Windows, Mac 混在環境
| ・当方リポジトリのパスには全角文字は含まれていません。
OSが同じvistal 32bitですので試してみました。
こちらではhg statusはcleanとなりました。
C:\Users\koie>hg init repo
C:\Users\koie>cd repo
C:\Users\koie\repo>echo aaa>file
C:\Users\koie\repo>hg add file
C:\Users\koie\repo>hg commit -m xxx file
C:\Users\koie\repo>echo bbb>>file
C:\Users\koie\repo>hg stat
M file
C:\Users\koie\repo>hg revert file
C:\Users\koie\repo>hg stat
? file.orig
C:\Users\koie\repo>hg version
Mercurial Distributed SCM (version 1.9+10-e9264b45237d)
(see http://mercurial.selenic.com for more information)
Copyright (C) 2005-2011 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
C:\Users\koie\repo>
--
鯉江英隆 <hi...@koie.org>
Shinobu Koyama
--
from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja
Yuya Nishihara
Shinobu Koyama wrote:
> 大丈夫とのことですのでローカルリポジトリを投稿します。
フジワラ wrote:
> 現象について補足します。
>
> - ローカルリポジトリ A で、あるファイルが modified 状態
> - hg diff 出力は:
> - ファイルモードの改変は無し
> - １行の差異が出力されるが、見た目は同一
> - 一番怪しいのは改行コードだが "hg revert" や "rm + hg update" しても改善なし
> - "hg update null + hg update tip" しても、modified 状態は変わらず
> - 別なリポジトリ B を clone すると、そちらは clean
> - A と B のファイルの差分を取ると、先だっての hg diff よりも多い差分が出力
添付されたファイルを見てみました。
差異はフジワラさんの仰られている通り、改行コードのようです。
(color エクステンションを使うと行末の空白と改行コードを強調表示してくれますよ!)
-<meta http-equiv="content-language" content="ja" /> ^M
+<meta http-equiv="content-language" content="ja" />
しかし、うちの環境では(Windows XP, Linux とも) hg revert や hg update null
で問題が再現しませんでした。
少し気になるのが TortoiseHg のファイル監視とアンチウィルスソフトのファイルロック問題
です。(#889)
恐らく関係無いとは思うのですが、問題が起きたときに TortoiseHg を起動していましたか?
https://bitbucket.org/tortoisehg/thg/issue/889/
あるいは、 Vista の UAC データリダイレクト ... は関係ないですよね、この場合。たぶん。
それでは。
--
SCMBC in 名古屋とか無いですかー?
フジワラ
On 7月31日, 午後3:41, Yuya Nishihara <you...@gmail.com> wrote:
> Shinobu Koyama wrote:
> > 大丈夫とのことですのでローカルリポジトリを投稿します。
> フジワラ wrote:
> > 現象について補足します。
>
> > - ローカルリポジトリ A で、あるファイルが modified 状態
> > - hg diff 出力は:
> > - ファイルモードの改変は無し
> > - １行の差異が出力されるが、見た目は同一
> > - 一番怪しいのは改行コードだが "hg revert" や "rm + hg update" しても改善なし
> > - "hg update null + hg update tip" しても、modified 状態は変わらず
> > - 別なリポジトリ B を clone すると、そちらは clean
> > - A と B のファイルの差分を取ると、先だっての hg diff よりも多い差分が出力
>
> 添付されたファイルを見てみました。
> 差異はフジワラさんの仰られている通り、改行コードのようです。
> (color エクステンションを使うと行末の空白と改行コードを強調表示してくれますよ!)
>
> -<meta http-equiv="content-language" content="ja" /> ^M
> +<meta http-equiv="content-language" content="ja" />
やはり改行コードでしたか。
ちなみに color ext での強調表示って、DOS 窓でも有効なんでしょうか？
> しかし、うちの環境では(Windows XP, Linux とも) hg revert や hg update null
> で問題が再現しませんでした。
>
> 少し気になるのが TortoiseHg のファイル監視とアンチウィルスソフトのファイルロック問題
> です。(#889)
> 恐らく関係無いとは思うのですが、問題が起きたときに TortoiseHg を起動していましたか?
>
> https://bitbucket.org/tortoisehg/thg/issue/889/
>
> あるいは、 Vista の UAC データリダイレクト ... は関係ないですよね、この場合。たぶん。
＃ 1.9 ベースの TortoiseHG なので警告表示がありました
一応、encode/decode 系設定はざっと確認したのですが、実は対称性が崩れていて
上手く変換が機能していないのを見落としていたかもしれません。
済みませんが、"hg showconfig" の出力を、ML に投げてもらえませんか？ > 小山さん
＃ 個人情報に絡む出力は削ってください
フジワラ
On 7月31日, 午後4:16, フジワラ <flying.fo...@gmail.com> wrote:
> １つ気になる点があって、小山さんの環境は、win32text が有効になっていました。
>
> ＃ 1.9 ベースの TortoiseHG なので警告表示がありました
>
> 一応、encode/decode 系設定はざっと確認したのですが、実は対称性が崩れていて
> 上手く変換が機能していないのを見落としていたかもしれません。
問題が発生しない、という点を考えると、encode/deocde 設定が:
- ~/.hgr 等でのアカウントワイドな設定 → 原因の可能性は低い
- .hg/hgrc でのリポジトリ毎設定 → 原因の可能性あり
というところなのですが、送っていただいたリポジトリを見る限りでは、
前者っぽいので、encode/decode の非対称性という可能性は低い感じ
ですねぇ。。。。。。
Yuya Nishihara
フジワラ wrote:
> > Shinobu Koyama wrote:
> > > 大丈夫とのことですのでローカルリポジトリを投稿します。
> > フジワラ wrote:
> > > 現象について補足します。
> >
> > > - ローカルリポジトリ A で、あるファイルが modified 状態
> > > - hg diff 出力は:
> > > - ファイルモードの改変は無し
> > > - １行の差異が出力されるが、見た目は同一
> > > - 一番怪しいのは改行コードだが "hg revert" や "rm + hg update" しても改善なし
> > > - "hg update null + hg update tip" しても、modified 状態は変わらず
> > > - 別なリポジトリ B を clone すると、そちらは clean
> > > - A と B のファイルの差分を取ると、先だっての hg diff よりも多い差分が出力
> >
> > 添付されたファイルを見てみました。
> > 差異はフジワラさんの仰られている通り、改行コードのようです。
> > (color エクステンションを使うと行末の空白と改行コードを強調表示してくれますよ!)
> >
> > -<meta http-equiv="content-language" content="ja" /> ^M
> > +<meta http-equiv="content-language" content="ja" />
>
> 検証、ありがとうございます ＞ 西原さん
>
> やはり改行コードでしたか。
>
> ちなみに color ext での強調表示って、DOS 窓でも有効なんでしょうか？
あ、強調表示は機能しますが、改行コード(^M)は見えませんでした。すいません。
^M を表示しているのはページャー(less)でした。 color.py の行末空白強調の
影響で ^M^J が 色指定^M色指定^J へ分割されるおかげで見えるみたいです。
Shinobu Koyama
> です。(#889)
> 恐らく関係無いとは思うのですが、問題が起きたときに TortoiseHg を起動していましたか?
Toshi MARUYAMA
On Jul 31, 5:16 pm, Shinobu Koyama <y015h1...@gmail.com> wrote:
> 小山です。こんにちは。
>
> ＞西原さん
>
> > 少し気になるのが TortoiseHg のファイル監視とアンチウィルスソフトのファイルロック問題
> > です。(#889)
> > 恐らく関係無いとは思うのですが、問題が起きたときに TortoiseHg を起動していましたか?
>
> 最初に問題に気がついた時には TortoiseHg は起動していました。
> その後、識者の方に見て頂いている中で TortoiseHg を終了させました。
関数上書きをするタイプの拡張は、thgw.exe内で一度有効になると、
全てのリポジトリで有効になってしまう問題があります。
win32mbcs/fixutf8が該当します。
TortoiseHg 2.x issue #984 Repo specific extensions are applied to all
registered repos in one workbench instance.
* https://bitbucket.org/tortoisehg/thg/issue/984
Mercurial-devel ML Re: Unicode Windows API, Was: Concerns about using
Python's ctypes library on Windows
* http://markmail.org/message/gjxcnoxefw2dgycm
あと、win32textを私は使ったことが無いのですが、EOL extensionに置き換わった気がしています。
その内部で関数上書きをしていると、問題が発生しているかもしれません。
Shun-ichi Goto
>> １つ気になる点があって、小山さんの環境は、win32text が有効になっていました。
>>
>> ＃ 1.9 ベースの TortoiseHG なので警告表示がありました
>>
>> 一応、encode/decode 系設定はざっと確認したのですが、実は対称性が崩れていて
>> 上手く変換が機能していないのを見落としていたかもしれません。
>
> 投函してから気が付きましたが、別なローカルリポジトリに clone した際には、
> 問題が発生しない、という点を考えると、encode/deocde 設定が:
>
> - ~/.hgr 等でのアカウントワイドな設定 → 原因の可能性は低い
> - .hg/hgrc でのリポジトリ毎設定 → 原因の可能性あり
>
> というところなのですが、送っていただいたリポジトリを見る限りでは、
> 前者っぽいので、encode/decode の非対称性という可能性は低い感じ
> ですねぇ。。。。。。
現状のリポジトリを見る限り team.html がLFベース＋1行だけCRLFという状態なので、
win32textでは扱い切れない状態になってます。まずはそこを直さないと。
それと1行だけCRLFが混在するようなテキストを作ってしまった原因ですが、
エディタ次第でそういうことが起きえます。手元で1行だけ直してセーブしたが、
その行はCRLFだけど、手をつけていないほかの行は元のまま(LF)なんてことが
起きたりします。自分のしててる例だと Visutal Studio でReSharperに using 整理を
自動でやらせた場合など。
改行コードが善行揃っているのに現在の不本意な modified が出るというのであれば
hg up -C すればいいかと。要は、hg revert は .hg/dirstate を作りなおす。
一度 hg st して .hg/dirstateが作られたあとでencode/decode 設定を変えると
変えるとそういう感じの症状になりがちです。今回のCRLF混在もその手の操作
によるものではないかなと思いますが。
こういう煩わしが付いて回るために win32textは廃止予定なわけですから、
win32text を使ってる人/リポジトリは早めに eol extension に移行するのが吉だと思います。
--
Shun-ichi GOTO
Katsunori FUJIWARA
2011年7月31日17:23 Shinobu Koyama <y015...@gmail.com>:
> 念のため hg showconfig の出力も投稿させて頂きます。
> フジワラさんに見て頂いたままの設定になっています。
１点、設定上の問題を見つけました。
decode.**=cleverencode:
encode.**=cleverencode:
"decode" の設定に「clever"en"code」が設定されているのは
明らかに設定ミスですね。
＃ っていうか、当日気付かずごめんなさい .... orz
ファイルの修正日付／サイズ等が更新されると、内容チェック（hash 値計算）が
走る筈なので、decode → encode の過程で内容の不整合が発生しますから、
hg diff/status が想定外になる件はこれで説明できると思います。
ただ、"hg update null && hg update tip" で clean 化しない件に関しては、
いまいち発生過程がひらめきません ....
--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
Katsunori FUJIWARA
2011年7月31日17:39 Shun-ichi Goto <shunic...@gmail.com>:
> 改行コードが善行揃っているのに現在の不本意な modified が出るというのであれば
> hg up -C すればいいかと。要は、hg revert は .hg/dirstate を作りなおす。
> 一度 hg st して .hg/dirstateが作られたあとでencode/decode 設定を変えると
> 変えるとそういう感じの症状になりがちです。今回のCRLF混在もその手の操作
> によるものではないかなと思いますが。
"hg update null" で作業領域を空（＝ 初期状態）にしてから、
"hg update tip" で最新状態にしてみたのですが、
現象は改善されなかったのですよ。
dirstate が更新されて、ファイルのタイムスタンプ／サイズ情報と同期されるので、
win32text:encode/decode 設定の問題は残るものの、hg の内部処理的には
status/diff 共に clean 扱いで通る(＝ ファイル内容のチェックまでは実施されない)
筈だと思うのですが .....
＃ team.html の古いファイルが残ってしまっていたのかな？
--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
Yuya Nishihara
Katsunori FUJIWARA wrote:
> > 改行コードが善行揃っているのに現在の不本意な modified が出るというのであれば
> > hg up -C すればいいかと。要は、hg revert は .hg/dirstate を作りなおす。
> > 一度 hg st して .hg/dirstateが作られたあとでencode/decode 設定を変えると
> > 変えるとそういう感じの症状になりがちです。今回のCRLF混在もその手の操作
> > によるものではないかなと思いますが。
>
> "hg update null" で作業領域を空（＝ 初期状態）にしてから、
> "hg update tip" で最新状態にしてみたのですが、
> 現象は改善されなかったのですよ。
>
> dirstate が更新されて、ファイルのタイムスタンプ／サイズ情報と同期されるので、
> win32text:encode/decode 設定の問題は残るものの、hg の内部処理的には
> status/diff 共に clean 扱いで通る(＝ ファイル内容のチェックまでは実施されない)
> 筈だと思うのですが .....
hg update tip のタイミングでおかしくなりますね。
Windows で hg up null; hg up tip した直後:
Z:\inbox\scmbc>python Z:\work\hghacks\mercurial\hg stat
win32text is deprecated: http://mercurial.selenic.com/wiki/Win32TextExtension
M team.html
? m.team.html
? team.html.org
? team.html.orig
その後 win32text を無効化して hg stat:
Z:\inbox\scmbc>python Z:\work\hghacks\mercurial\hg stat
? m.team.html
? team.html.org
? team.html.orig
Mercurial.ini はこういう状態です ([encode] だけ設定してみました):
[extensions]
win32text =
[encode]
** = cleverencode:
[decode]
;** = cleverdecode:
Shun-ichi Goto
> dirstate が更新されて、ファイルのタイムスタンプ／サイズ情報と同期されるので、
> win32text:encode/decode 設定の問題は残るものの、hg の内部処理的には
> status/diff 共に clean 扱いで通る(＝ ファイル内容のチェックまでは実施されない)
> 筈だと思うのですが .....
あぁ、なんとなく昔同じようなことで悩んだような。
hg debugstate でみると、unset になってますね。
だから毎回内容比較してるのだと思います。
unsetになる理由の詳細は確かめてませんが、EOL変換がうまくない場合に
セットされないんだと思います。
hg up 0 してから hg up -C tip すると、
WARNING: team.html already has CRLF line endings
が出て、以降の debugstate, st, 再debugstate は以下の状態
[c:\temp\scmbc]hg debugstate
win32text is deprecated: http://mercurial.selenic.com/wiki/Win32TextExtension
n 0 -1 unset index.html
n 0 -1 unset local.html
n 0 -1 unset team.html
[c:\temp\scmbc]hg st
win32text is deprecated: http://mercurial.selenic.com/wiki/Win32TextExtension
M team.html
? m.team.html
? team.html.org
? team.html.orig
[c:\temp\scmbc]hg debugstate
win32text is deprecated: http://mercurial.selenic.com/wiki/Win32TextExtension
n 666 396 2011-07-31 18:26:32 index.html
n 666 839 2011-07-31 18:26:32 local.html
n 0 -1 unset team.html
なんにせよ、win32textでLFに正規化するつもりならば、team.html の r35 に混入した
CRLFな行(3行目のcontent-language行)を正しいものに解消しないと。
encode/decode設定を正しく直した後に、単純にコミットすればいいと思います。
ただし、tipはそれで良くなりますが、あとでr35に戻ったときに似たような症状が
出ます。encode/decode設定はrevに連動しないためです。そこらへんがeolが導入
された動機でもあります。
自分しか使ってないならば mq で r35 自体を修正してしまうほうがいいかも。
--
Shun-ichi GOTO
Toshi MARUYAMA
On Jul 31, 3:41 pm, Yuya Nishihara <you...@gmail.com> wrote:
> 西原です。こんにちは。
>
> Shinobu Koyama wrote:
> > 大丈夫とのことですのでローカルリポジトリを投稿します。
> フジワラ wrote:
> > 現象について補足します。
>
> > - ローカルリポジトリ A で、あるファイルが modified 状態
> > - hg diff 出力は:
> > - ファイルモードの改変は無し
> > - １行の差異が出力されるが、見た目は同一
> > - 一番怪しいのは改行コードだが "hg revert" や "rm + hg update" しても改善なし
> > - "hg update null + hg update tip" しても、modified 状態は変わらず
> > - 別なリポジトリ B を clone すると、そちらは clean
> > - A と B のファイルの差分を取ると、先だっての hg diff よりも多い差分が出力
>
> 添付されたファイルを見てみました。
> 差異はフジワラさんの仰られている通り、改行コードのようです。
> (color エクステンションを使うと行末の空白と改行コードを強調表示してくれますよ!)
>
> -<meta http-equiv="content-language" content="ja" /> ^M
> +<meta http-equiv="content-language" content="ja" />
tip 36:c1fc62f9a67d にコミットされているものの３行目がCRLFでそれ以外がLFになっています。
vimで見るのが一番手っ取り早かったりします。
改行コード混在の問題は悩ましいものです。実はこれが・・・
https://bitbucket.org/redmine/redmine/src/e11f046a87c6/db/migrate/001_setup.rb
Shinobu Koyama
> ＃ っていうか、当日気付かずごめんなさい .... orz
Shinobu Koyama
Shun-ichi Goto
> r36 に残る問題ですが、勉強会の演習で使ったリポジトリなので
> もう使うことはないと思います。
> しかし、今後このような状況になったときのために MQ について
> 使いどころと使い方が分かるように調べます。
mqで、といったのはr36の内容を書き換えて、半端なrevを残さないようにして
しまうということです。今はすでに r37 かと思いますので以下のように：
hg qimp -r 36:37
hg qpop
(edit team.html to fix CRLF)
hg qrefresh
hg qrm 37.diff
hg qfinish -a
あるいは
hg qimp -r 36:37
hg qpop
hg qfold 37.diff
hg qrefresh --edit # (edit commit log)
hg qfinish -a
とかでしょうか。出来上がったものは tip = r36 になります。
あと、上記操作は encode/decode設定を外して行ったほうが間違いが少ないかも。
mqによる「いじり」は超絶役に立ちますので覚えると幸せになれると思います。
リポジトリをいじることになるため過信するとハマるので練習が必要ですが。
> このような状態になってしまった原因は 「1行だけ CRLF な行を混入させて
> しまった」で確定でしょうか。
> となると使い方が悪かったのですね…（Mercurial の使い方以前の問題）
確定かどうかはわかりませんが、自分がやったこと、使ったツールを用いて再現してみる
というのもいいかもしれません。
--
Shun-ichi GOTO
Shinobu Koyama
> リポジトリをいじることになるため過信するとハマるので練習が必要ですが。
フジワラ
On 7月31日, 午後6:37, Shun-ichi Goto <shunichi.g...@gmail.com> wrote:
> > dirstate が更新されて、ファイルのタイムスタンプ／サイズ情報と同期されるので、
> > win32text:encode/decode 設定の問題は残るものの、hg の内部処理的には
> > status/diff 共に clean 扱いで通る(＝ ファイル内容のチェックまでは実施されない)
> > 筈だと思うのですが .....
>
> あぁ、なんとなく昔同じようなことで悩んだような。
> hg debugstate でみると、unset になってますね。
> だから毎回内容比較してるのだと思います。
> unsetになる理由の詳細は確かめてませんが、EOL変換がうまくない場合に
> セットされないんだと思います。
実施されるのかと思ったのですが、違うんですね。
他のリポジトリ(selenic.com の hg の clone)で試してみたところ、
null → tip の hg update の際に、15% ぐらいのファイルが dirstate の
キャッシュ情報を持ってませんでした。
＃ 作業領域への書き出し時間に対して、一定時間で打ち切っているとか？＞ハッシュ計算
> hg up 0 してから hg up -C tip すると、
> WARNING: team.html already has CRLF line endings
> が出て、以降の debugstate, st, 再debugstate は以下の状態
>
> [c:\temp\scmbc]hg debugstate
> win32text is deprecated:http://mercurial.selenic.com/wiki/Win32TextExtension
> n 0 -1 unset index.html
> n 0 -1 unset local.html
> n 0 -1 unset team.html
>
> [c:\temp\scmbc]hg st
> win32text is deprecated:http://mercurial.selenic.com/wiki/Win32TextExtension
> M team.html
> ? m.team.html
> ? team.html.org
> ? team.html.orig
>
> [c:\temp\scmbc]hg debugstate
> win32text is deprecated:http://mercurial.selenic.com/wiki/Win32TextExtension
> n 666 396 2011-07-31 18:26:32 index.html
> n 666 839 2011-07-31 18:26:32 local.html
> n 0 -1 unset team.html
ちなみに、cygwin 上でソースからビルドした 1.8.4/1.9 だと、
同じ現象は発生するものの、"WARNING: team.html already has CRLF line endings" は
出力されませんでした。
＃ 小山さんの環境でも確か出てなかった筈
ソースを見る限りでは表示されてもよさそうなものなのですが....
まぁ、deprecated な拡張に関して、これ以上首を突っ込むのも微妙ですが (^ ^;;;)
フジワラ
On 7月31日, 午後8:50, Shinobu Koyama <y015h1...@gmail.com> wrote:
> 勉強会の演習でも MQ という単語が飛び交っていました。
> # strip という単語もずいぶん…
出来れば rollback や backout で済ませるほうが安心です (^ ^;;;)
＃ 「やりなおし」の「やりなおし」が出来ますし > backout
但し、Mercurial 本執筆時点から、backout の挙動が変わっていますので、
以下の記載内容をお読みください。
http://d.hatena.ne.jp/flying-foozy/20101029/1288366323
> コマンドの使用法について身につけるのはもちろん、Mercurial 本を買って考え方
> からしっかりと勉強しようと思います！
不明な点／誤植／間違い等ありましたら、ML への投函でも良いですし、
以下の私のブログエントリへのトラックバック等でも良いですので、
是非お知らせください。
http://d.hatena.ne.jp/flying-foozy/20140125/1233753098
Shinobu Koyama
> 出来れば rollback や backout で済ませるほうが安心です (^ ^;;;)
フジワラ
On 7月31日, 午後11:20, Shinobu Koyama <y015h1...@gmail.com> wrote:
> > strip はかなり「最後の手段」ですので、「履歴の綺麗さ」にこだわりが無ければ、
> > 出来れば rollback や backout で済ませるほうが安心です (^ ^;;;)
>
> アドバイスありがとうございます。
> strip を使わずに済ませられるように＆最後の手段としていつでも使えるように
> なることを目標にします！
>
> ただ、backout も「基本的にやっちゃダメ！」と聞いたような…？
>
> # 私のチームは strip したうえで backout しました…
> # 他のチームでも strip を使ったところがあった模様
1. 間違った操作内容を commit → これをリビジョン "A" とする
2. 他の操作内容を commit → B、C、..... Z
3. B ～ Z を strip → BUNDLE で保存
4. A を backout
5. (3) の BUNDLE を unbundle で復旧
ということでしょうか？
ちなみに、上記手順だと、(5) の unbundle 結果は A にぶら下がりますので、
最終的には複数ヘッド状態になって、(4) 結果とのマージが必要になるはずです。
＃ unbundle しないと B ～ Z の成果まで無駄に ... orz
また、(4) で backout ではなく strip を実施すると、(5) での unbundle の際に
"unknown parent" で abort します。
＃ 「A を strip」だと、そもそも「A の backout」が出来ませんし ....
うーん、まぁ、操作としては間違ってませんが、結局 backout するなら
strip なんかしないで backout (+ マージ)の方が簡単／安全だと思いますが ....
兎に角、「strip したうえで backout」がどういう手順なのか、非常に興味があります！
＃ あるいは Git の話と混同してしまっているとか？
Toshi MARUYAMA
On Jul 31, 11:20 pm, Shinobu Koyama <y015h1...@gmail.com> wrote:
> 小山です。こんばんは
>
> > strip はかなり「最後の手段」ですので、「履歴の綺麗さ」にこだわりが無ければ、
> > 出来れば rollback や backout で済ませるほうが安心です (^ ^;;;)
>
> アドバイスありがとうございます。
> strip を使わずに済ませられるように＆最後の手段としていつでも使えるように
> なることを目標にします！
>
> ただ、backout も「基本的にやっちゃダメ！」と聞いたような…？
共有リポジトリにpushした後だと、そのリビジョンをすでに誰かがpullしているはずなので、
基本的にstripをしてはいけません。
この場合はbackoutをするべきです。
共有リポジトリにpushする前であれば、strip、ないしは、MQのqimportが優先です。
gitの場合も、共有リポジトリにpushしたあとは、
rebaseなどの履歴の改変はあまりやってはいけないことになっているようです。
しかし、gitでは、リモートリポジトリのブランチも、
(確か設定で許可していれば)コマンド一発で削除できます。
git push どこそこ :削除するブランチ
Mercurialで、同様のことをしようとすると、リビジョングラフで根元のリビジョンを探して、
そのリビジョンをstripする必要があります。
Shinobu Koyama
小山です。おはようございます。
strip + backout ではなく strip ( + マージ) だったかもしれません。
帰宅したら整理して投稿します！
2011/08/01 0:15 "フジワラ" <flying...@gmail.com>:
Shinobu Koyama
小山です。
状況としては bitbucket の共有リポジト}> まるやまです。
Shinobu Koyama
フジワラ
On 8月1日, 午後11:16, Shinobu Koyama <y015h1...@gmail.com> wrote:
> 頭の中で状況を整理したのですが、 やはり backout はしなかったと思います。
> 重ね重ね申し訳ありません。
>
> http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html
>
> ここの Figure 9.5. A bad merge に該当するような状況になっていたようです。
> そして、「backout は基本的にしてはいけない」ということと「操作が難しいため、
> Mercurial 初心者チームが時間制限のある中で実施するとミスが発生しかねない」
> ということで backout せずに head (?) を strip してブランチを merge していきました。
>
> なので、 strip （bitbucket 上の共有リポジトリに実施）+ マージ な操作でした。
> 軽率な発言、大変失礼いたしました…
「マージ」という概念そのものに慣れるまでは backout は危険、というのは確かで、
特にチームで作業している場合は、混乱の元になる可能性が高いです。
＃ backout というよりは、マージ作業そのものの難度なのですが....
ちなみに、"figure 9.5 bad merge" は新版の hg book で追加された内容ですね。
旧版にはなかったのですが、やはりマージが絡むと、混乱する人が多かったのでしょうねぇ。
＃ http://foozy.bitbucket.org/hgbook-ja/d6ca1334a19d/hgbookch9.html