一応はっきり書いておいたほうがいい？
まー、最近は、独自の解決方法を各社が持っていて、
問題になることはないんだけどね・・・
■一般のトランザクションとのちがい
一般のトランザクションは、ＡさんとＢさんが
・いくつかの資源を更新する
・同じ資源も更新するため
・利用する資源全体に排他的ロックをかけて、更新を行う。
という手法をとる
ロングトランザクションは、
・ＡさんＢさんが、同時進行で１つのことを編集しなければいけないことが分かっているときに
→なので、排他的ロックがかけられないときに
・この編集対象が半構造データであり、単純にマージすると、論理的な矛盾を起こすことが
分かっている
→半構造とは限らないけど、半構造がおおい。
正規化されていると矛盾が起こりにくく
全く構造がないなら、マージできない。
状態でのトランザクション処理。
大きな違いは、
・ロックをかけられない
・マージするだけでは矛盾を起こす→補正処理が必要
ってことになる。
■具体的にはどんな処理？
たとえば、いつもの電波利用の例でいうと、
・無線局事項書
・工事設計書
・無線局免許申請書
の３つのテスト仕様書をＥｘｃｅｌで書こうとしたとき、
Ａさんは、無線局事項書と、無線局免許申請書を
Ｂさんは、量が多いので工事設計書のテスト仕様書を書くとします。
このとき、プログラムに番号をつけるのですが、プログラムは、画面グループごとの連番とすることにします。
つまり、番号は
・無線局事項書 Ａさん担当
・工事設計書 Ｂさん担当
・無線局免許申請書 Ａさん担当
で、連番が振られます。
テスト仕様書は、表紙と、仕様書からなり、表紙には、トータルのテスト件数が、かかれるものとします。
ここで、
・Ａさん、Ｂさんとも、たまたま１００件ずつテスト項目が挙がり、
・Ａさん、Ｂさんとも、（テストはじめには何件かわからないので）仮番をふっておいて、
試験中、前の試験結果をもとに試験を行う場合には、「ＮＯ（仮番番号）の結果を元に」
（例「Ｎｏ５の操作を行った後、Ｎｏ８を行った状態で」）のように、仮番を元に、
仕様書を記載している。
■この場合、何が問題か
まあ、Ｅｘｃｅｌなんで、Subversionで競合がわかるかという問題はさておき、かりに、分かったとしても、上記のケースの場合、
・件数のところ、自分のテスト項目件数は、たまたま２人とも１００件なので
２人とも１００件と書いてある
→同じ言葉（１００件）が書いてあるので、ＤＩＦＦをとっても検出できない
→しかし、マージしたら２００件になるので、ここを修正しないといけない。
・マージの仕方に順番があり（Ａさんの途中にＢさんの結果を入れる）、その方法が
かならずしも、作業者に分かっているとは限らない
（Ａさん、Ｂさんの関係を、マネージャーしか知らないかも・・・）
・マージしただけではだめで、仮番の結果を修正しないといけない。
→どこが修正箇所で、どのように修正するか（仮番を正式番号に置き換える）
のような問題があります。
一般的にロングトランザクションの場合は、マージする際に、
・マージする仕方が決まっているが、それをどのようにやるか
・マージした結果、矛盾するところがあるが、それをどのように修正するか？
ということが問題になり、これを確実に行うために、どうするか？
(人手でやるか、コンピューター化するか）
などが問題になります。
つまり、
Subversion(TortoiseSVN)でコンフリクト(競合/衝突)を解決する方法(手順)
http://hide.xsv.info/tips/svnmanual/conflict/
の説明で言う、「競合を解決できるように編集してください」と書いてあるけど、具体的にどのように編集するの？という話です（そこは書いてないように読めますけど・・・）。
■どのように解決しているか
ここで、Ｅｘｃｅｌを使っている意味があるのですが・・・
・はじめから、ＡさんＢさんのＥｘｃｅｌシートを分けておく
・マージする結果シートを用意しておき、結果シートでは
・２人のＥｘｃｅｌシートを読み込み、
・仮番から正規番号に変換するシートをつくって、その結果をもとに、仮番を直して
・その結果をマージする
を実行するＥｘｃｅｌマクロを組んでおき、結果シートを開いたごとに、実行する。
その際、
・全体件数などはＥｘｃｅｌの式で書いてあるので、開いたごとに再計算される
というようなＥｘｃｅｌシート（ブック）を用意しています。
（なので、Ｅｘｃｅｌでテスト仕様書を作ると便利便利・・・なんですよね）
ＤＴＰにおいては、ライブラリを用意して、小組レベルをいれといてもらい
全体レイアウトは、ライブラリの内容を流し込めばできるようにしてあるかな。
そのとき、読み込み順番によっては、図が重なるところとか、へんな風に重なっちゃうかもしれないから
目で確認して、なおさないといいけない。
なので、バッチより、ＤＴＰのほうが便利っていうことになる。
■これって、最近話題にならないよね・・・
上記のように、Ｅｘｃｅｌで自動編集までやらなくても、
・マージしても大丈夫なようなソースわけ
・マージした後の責任者を置き、その人たちがマージしたり、チェックしたりする
などで、回避してると思う。なので、問題にはならないかな・・・
（こっちのほうが、いままで行ったソフト会社では多い。
ＤＴＰ関係のお客様だと、ライブラリにして、そのあとは手作業、自動組版、いろいろありますね）
ってことで、最近は問題にならない。
ちなみに、1月29日(金)のつぶやきで書いた新人が、「コミットするとき、確認すればいいんですね！」は、
Subversion(TortoiseSVN)でコンフリクト(競合/衝突)を解決する方法(手順)
http://hide.xsv.info/tips/svnmanual/conflict/
の説明で言う、「競合を解決できるように編集してください」の、編集をすればいいんですね！
の意味で、新人は、使っている。
で、やばすぎるといったのは、いままで説明したように、「編集するのは、当然なんだけど、編集する箇所はわかっていて、その上で、あなたは、すべて、人手で確実に編集できるの？」っていう意味あい。
数年前までは、現場で、この確認はしてた（２００２年ごろ行った会社では、確認した）けど、さいきん、この手の確認を聞かないので一般的になった・・・っていうか、矛盾しないようにＥｘｃｅｌ化してるってのは、あるよな・・・
アクセス
トータル
ランキング
