--- a/slides/index.html	Mon Feb 03 08:40:32 2014 +0900
+++ b/slides/index.html	Mon Feb 03 09:43:16 2014 +0900
@@ -125,10 +125,10 @@
 	</h3>
 	<p>Webコンテンツを構成するテキストや画像などのデジタルコンテンツを管理し配信するシステム。</p>
 	<li>例：ブログツール、Wiki</li>
-	<p>『分散』コンテンツマネジメントシステムに求められること。</p>
+	<p>分散コンテンツマネジメントシステムに求められること。</p>
 	<li>Webコンテンツを分散して管理</li>
 	<li>スケールアウトするシステム</li>
-	<p>データ全体の整合性に遅延がある結果整合性でも問題なく。書き込みや読み込みを優先としたデータベースが必要。</p>
+	<p>データ全体の整合性に遅延がある、結果整合性でもよい。書き込みや読み込みを優先としたデータベースが必要。</p>
 	<p>そこで、非破壊的木構造データベースJungleの提案を行った。</p>
       </article>
 
@@ -214,8 +214,8 @@
 	<p style="margin-top:-10px;">分散版管理システムとは多人数によるソフトウェア開発において変更履歴を管理するシステム</p>
 	<p style="margin-top:-10px;">分散版管理システムは次の特徴とAPIを持つ</p>
 	<ul>
-	    <li>開発者それぞれがリポジトリのクローンを持ち、開発はローカルのリポジトリを通すことで行われる</li>
-	    <li>ローカルのリポジトリは独立に存在し、サーバ上ある他人のリポジトリから変更履歴をとることができる。また自身の変更履歴を伝えることもできる</li>
+	    <li>開発者それぞれがリポジトリのクローンしてローカルに持ち、開発はローカルのリポジトリを通すことで行われる</li>
+	    <li>ローカルのリポジトリは独立に存在し、サーバ上にある他人のリポジトリから変更履歴をとることができる。また自身の変更履歴を伝えることもできる</li>
 	    <li>データ更新時に先に別の更新が入っていた(衝突)場合はMergeによりデータの整合性をとる</li>
 	</ul>
       </article>
@@ -234,8 +234,8 @@
 	<img style="height:200px;" src="./images/distributed_repository.png">
 	</p>
 	<small>
-	<p>分版版管理システムはリポジトリが壊れても別のリポジトリよりデータを復旧できることと、いつでも
-	読み込みが可能なため、高いスケーラビリティを持っている</p>
+	<p>分版版管理システムはリポジトリが壊れても別のリポジトリよりデータを復旧できることと、push/pullそれとMergeによる整合性
+	    の確保で、高いスケーラビリティを持っている</p>
 	</small>
       </article>
 
@@ -292,12 +292,43 @@
 	</small>
       </article>
 
+      <article>
+        <h3>
+	    Mergeによる更新の衝突の解決
+	</h3>
+	<small>
+	<table style="font-size: 0.7em; width:100%;" >
+	    <tr>
+		<td><p style="margin-top:-5px; margin-bottom:-5px; text-align:center;"><img src="./images/tree_conflict.png"></p></td>
+	    </tr>
+	    <tr>
+		<td><p style="margin-top:-5px; margin-bottom:-5px; text-align:center;"><img src="./images/tree_conflict3.png"></p></td>
+	    </tr>
+	</table>
+	<p style="margin-top:0px;">上の図は通常のデータ更新を示す</p>
+	<p style="margin-top:-20px;">下の図は、同じ木に対して2つのデータの更新があったが編集を無事終えるケースを示す</p>
+	</small>
+      </article>
+
+      <article>
+        <h3>
+	    Mergeによる更新の衝突の解決ができない場合
+	</h3>
+	<table style="font-size: 0.7em; width:100%;" >
+	    <tr>
+		<td><p style="margin-top:-5px; margin-bottom:-5px; text-align:center;"><img src="./images/tree_conflict2.png"></p></td>
+	    </tr>
+	</table>
+	<p>木の同じノードに対してデータの編集が行われた場合、どのような編集結果にすればよいかわからない。</p>
+	<p>どのような木が組まれ、どのようにデータを保存するかはアプリケーション毎に変わってくる。そのため、アプリケーション毎に
+	Mergeアルゴリズムは考えなくてはならない。</p>
+
+      </article>
 
       <article>
         <h3>
 	    Jungleの分散実装:掲示板システムにおけるMerge
 	</h3>
-	<p>Mergeとはデータ更新の衝突が起きた際の解決方法</p>
 	<p>Jungleではアプリケーション毎にMergeアルゴリズムを設計</p>
 	<p>後述する性能比較に用いた掲示板システムにおけるMergeの実装を考える</p>
 	<p>掲示板システムにおけるデータ構造を以下に示す</p>
@@ -328,7 +359,6 @@
 	</small>
       </article>
 
-
       <article>
         <h3>
 	    分散データベースJungleの評価
@@ -634,6 +664,16 @@
 
       <article>
         <h3>
+	    Mergeは必ずできるのか
+	</h3>
+	<p>Mergeを必ず行うことは難しい</p>
+	<p>例えば、更新するデータが画像だった場合、2つの画像のデータから新しい画像を作るわけにはいかない。</p>
+	<p>後に更新したものを優先するといった方法をとるか、ユーザの選択に委ねるしかない。</p>
+      </article>
+
+
+      <article>
+        <h3>
 	    分散Key-ValueストアCassandraの特徴
 	</h3>
 	<small style="line-height:30px;">