社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

修正の分類に基づいたコミット分割手法の提案
楠

野明†

堀田

圭佑†

肥後 芳樹†

楠本真二†† 大阪大学大学院情報科学研究科，吹田市
E-mail: †{k-noa,k-hotta,higo,kusumoto}@ist.osaka-u.ac.jp
あらましソフトウェアリポジトリマイニングが広く注目されている．これはソフトウェアリポジトリから将来の開発及び保守作業に有用な知見を得ようとする研究である．ソフトウェアリポジトリマイニングにおいて，ビッグコミッ
トを解析対象から除外する処理が行われる．ビッグコミットとは大規模な修正をリポジトリに反映するコミットである．ビッグコミットはフォーマットの修正を多く含むことが指摘されており，そのため分析対象から除外される．しかし，ビッグコミットはフォーマットの修正と同時に分析すべき情報も含む場合があるため，ビッグコミットの除外
によってそれらが失われている．よってリポジトリマイニングの結果が正確でなくなっている可能性がある．この問題を解決するため，本研究ではコミットに含まれる修正を分類し，それに基づいてコミットを分割する手法を提案する．これによって，コミットに含まれる分析すべき修正のみを対象とした解析が可能となる．
キーワード

ソフトウェアリポジトリマイニング，版管理システム，コミット，最長共通部分列

Dividing commits based on classification of modifications
Noa KUSUNOKI† , Keisuke HOTTA† , Yoshiki HIGO† , and Shinji KUSUMOTO†† Graduate School of Information Science and Technology, Osaka University, Suita-shi, 565-0871, Japan
E-mail: †{k-noa,k-hotta,higo,kusumoto}@ist.osaka-u.ac.jp
Abstract Many researchers have mined software repositories to gain knowledge or principles that can encourageeﬃcient software development. Historical code repositories are one of the well-mined repositories. In mining historical code repositories, researchers often omit big commits from their mining targets. A big commit indicates acommit that modifies many source files or many lines of code. The reason of the preprocessing is that it is said
that most of modifications included in big commits were trivial ones such as re-formatting of source code. However,nobody can say that all of such modifications are trivial without any exception. In other words, big commits can
include non-trivial modifications on code. Hence, omitting big commits should reduce the accuracy of the mining.
This paper proposes a method that divides a commit into multiple commits based on types of modifications. The
proposed method enables us to retrieve valuable information that was discarded by ommiting big commits.
Key words software repository mining, version control system, commit, longest common subsequence

1. ま え が き

コミット（注 1）のうち修正が大規模（注 2）なものを指す．その理由として，ビッグコミットにはソフトウェアの振る舞いに影響を与

近年，ソフトウェアリポジトリマイニングに関する研究が注える修正が少ない，という点がある [8]．また，一度のコミット目されている [1]〜[5]．ソフトウェアリポジトリとはソフトウェで加えられる修正は規模が小さいものがほとんどである [9]．そア開発にかかわる様々な情報を蓄積したものである．ソフトのため，ビッグコミットを分析対象とすると，本来分析したい

ウェアリポジトリマイニングとは，このソフトウェアリポジト

ソフトウェアの振る舞いに影響する修正が，分析結果に及ぼすリを分析し，ソフトウェアを開発するうえで有益な知見を得る

影響が現れにくくなってしまう．よって，ビッグコミットを分ことを目的とした研究分野である．ソフトウェアリポジトリに析対象から除外するという前処理がしばしば行われている．しは，過去に行われた修正内容や，不具合の記録，開発中にやり取りされた電子メールなど様々な情報が蓄積されている [6], [7]．
ソフトウェアリポジトリマイニングでは，前処理としてビッグコミットを対象から除外することが多い．ビッグコミットとは（注 1）：コミットとは修正をリポジトリに反映する操作（注 2）：ここでいう大規模とは一度に修正が加わったファイル数や，行数が多いことを意味する．

—1—

行番号

修正前のソースコード

行番号

1
2
…
35
36
37
38
39
40
41
42
…
302
303
304
305
306
307
…
431
432

package net.sourceforge.squirrel_sql.fw.util;/*…
private interface ActionProperties{
String DISABLED_IMAGE = "disabledimage";
String IMAGE = "image";
String NAME = "name";
String ROLLOVER_IMAGE = "rolloverimage";
String TOOLTIP = "tooltip";
}
…
}
else
{
s_log.debug("No resource found for " + keyName + " : "+ propName);
}
…
}

1
2
3
…
36
37
38
39
40
41
42
43
44
45
46
47
…
301
302
303
304
305
306
307
…
425
426

修正後のソースコード
package net.sourceforge.squirrel_sql.fw.util;/*…
private interface ActionProperties{
String DISABLED_IMAGE = "disabledimage";

String IMAGE = "image";
String NAME = "name";
String ROLLOVER_IMAGE = "rolloverimage";

String TOOLTIP = "tooltip";}…

} else{if (s_log.isDebugEnabled()){
s_log.debug("No resource found for " + keyName + " : " + propName);
}

}
…
}

図 1 複数種類の修正が行われる例

かし，ビッグコミットの中にソフトウェアの振る舞いに影響を修正箇所：与える修正が含まれていた場合，このような前処理によって本

手法適用前

手法適用後

(リビジョンr)
public void A(){method1();
method2();}(リビジョンr’)
public void A(){method1();
method2();}

来は分析すべき修正も除外してしまう．
本研究ではこの問題を解決するために，ソースコードに加えられた修正を分類し，その分類に基づいてコミットを分割する手法を提案する．コミット自体を分割する方法はこれまでに提(リビジョンr’+1)
public void A(){method1();
method2();}

案されていない．提案手法では，ソースコードに加えられた修正を以下の三種類に分類する．

•

プログラムコードの修正•

フォーマットの修正•

コメントの修正(リビジョンr’+2)
public void A(){method1();//Delete Method
method2();}提案手法をツールとして実装し，評価実験を行った．複数のソフトウェアに対して実験を行った結果，その開発者自身による修正の分割を正解としたとき，提案手法による修正の分割の(リビジョンr+1)
public void B(){method1();//Delete method}

適合率は約 67%となり，再現率は約 72%という結果になった．

2. 研 究 動 機
図 1 は，オープンソースソフトウェアの “SQuirreL SQL(リビジョンr’+3)
public void B(){method1();//Delete method}

図 2 提案手法適用による修正分類の例

Client” のリポジトリに対して行われたあるコミットにおける修正を示している．このコミットでは 100 行程度にフォーマッるコミットを分割した後のコミットを出力する．コミットは 4.

トの修正が行われ，303 行目，304 行目および 306 行目では文にて説明する手順で分割される．

の追加が行われている．図 1 のような修正が，ビッグコミット

実際に提案手法を適用した際に，修正の加わったソースファを除外する前処理によって除外された場合，303 行目，304 行

イルにおいて，行われていた修正がどのように分割されるかと目，306 行目の文の追加が見落とされるという問題が起こる．

いう例を図 2 に示す．図 2 では提案手法適用前のリビジョン r

上記の問題は，一つのコミットに存在するフォーマットの修正のソースファイルとリビジョン r + 1 のソースファイル間で，と数行の文の追加を分離し，二つに分割された修正を別々にコ

以下の四つの修正が行われている．

ミットすることによって解決できる．そこで本研究では一つの•インデントの削除

コミットに含まれる複数種類の修正を別々のコミットに分割す•コメントの追加る手法を提案する．

•

文の追加

3. 提 案 手 法•

字句単位の変更提案手法を適用した結果，ソースファイルにおいてはリビジョ

3. 1 概要

提案手法はリポジトリを入力とし，入力リポジトリに含まれ

ン r ′ から r ′ + 3 の間で分割された修正が別々のコミットで行われた修正として保管される．

—2—

3. 2 分類の定義

ステップ 1：字句列の取得

コミットを分割する際に行われる修正の分類では，コミット

ステップ 2：修正前後における字句の対応の特定に含まれる修正を以下に定義する四種類に分類する．

ステップ 3：字句に行われた修正の分類

修正 A

フォーマットの修正ステップ 4：コミットの分割

修正 B

コメントの修正以降では各ステップで行われる処理を説明する．

修正 C プログラムコードの修正，およびソースファイルの追ステップ 1：字句列の取得

加・削除

ファイ ル F が あ る コ ミット で 修 正 さ れ て い た 場 合 ，そ修正 D

ソースファイル以外のファイルの修正，およびソース

ファイル以外のファイルの追加・削除の 修 正 前 の リ ビ ジョン を Fbef ore ，修 正 後 の リ ビ ジョン を

Faf ter とする．これらを入力として字句解析を行い，字句

ただし，修正 A におけるフォーマットの修正とは，空白，タブ，および改行文字の修正のことである．

列 Tbef ore = ⟨x1 , x2 , . . . , xl ⟩，および Taf ter = ⟨y1 , y2 , . . . , ym ⟩を取得する．

3. 3 用語の定義

ステップ 2：修正前後における字句の対応関係の特定

本節では以降の説明で必要となる諸用語の定義を行う．

ステップ 1 で取得した字句列 Tbef ore ，Taf ter について字句列［Definition 3.1］（列） n 以下のすべての自然数からなる集に含まれる字句の対応関係を特定する．対応関係は以下の二種合を I とする．このとき，ある集合 X に対して I を定義域と類存在する．

する写像 ϕ : I → X を列と呼び，ϕ = ⟨x1 , x2 , . . . , xn ⟩(∀i ∈

文字列対応関係 字句を表す文字列の一致に基づく字句同士の1..n[i ∈ I ∧ xi ∈ X]) と表記する．また ϕ の逆像を fϕ とする．

対応関係

例えば ϕ(i) = xi であるとき，fϕ (xi ) = i となる．以降，ϕ の種類対応関係定義域を Iϕ ，値域である集合 X を，Vϕ とする．
［Definition 3.2］（部分列） ϕ : I → X と表記される列 ϕ にそれぞれ以下のように求める．
文字列対応関係の取得方法

対して，I の部分集合 I ′ (I ′ ⊂ I) を定義域とする写像 ϕ′ を部分列と呼ぶ．

まず Tbef ore ，Taf ter の最長共通部分列を求める．その際，最長共通部分列が複数存在した場合はいずれか一つを用いる．そ［Definition 3.3］（共通部分列） 二つの列 A, B を考える．こ′′のとき以下の条件を満たす部分列 A ，B を共通部分列と呼ぶ．
′′′の最長共通部分列を Tbef
ore ，Taf ter としたとき，Tbef ore の要

素 xi と Taf ter の要素 yj が以下のすべての条件を満たす時，xi•

A は A の部分列である．

•

B ′ は B の部分列である．

••|IA′ | = |IB ′ | となる．

•

|IA′ | = |IB ′ | = m として ∀i ∈ 1..m[ai = bi ] となる．

••

字句の種類の一致に基づく字句同士の対応関係［Definition 3.4］（最長共通部分列） 二つの列 A，B に対してと yj は文字列対応関係を持つといい，xi ⇔ yj と表す．

［Definition 3.5］（字句） 字句は，字句を表す文字列と字句′
yj ∈ VTaf
ter
′
′
fTbef
(xi ) = fTaf
(yj )
ore
ter

種類対応関係の取得方法′′
Tbef ore の 要 素 xi ，xu (xi ，xu ∈ VTbef∧ fTbef(xi ) =oreore

複数の共通部分列が存在するとき，その中で要素数が最大のものを最長共通部分列と呼ぶ．

′
xi ∈ VTbef
ore

w

′
∧ fTbef(xu ) = w + 1) と Taf ter の 要 素 yj ，yv (yjore′′，yv ∈ VTaf
∧ fTaf(yj ) = w
ter
ter

′
∧ fTaf(yv ) = w + 1)
terの種類の情報を持つ．K を字句の種類の集合としたとき，字の間で，xi ⇔ yj ，xu ⇔ yv であると仮定する．また，Tbef ore

句 t は t = (s, k) と表記される．ここで，s は文字列を表し，kに関して，{i + 1, . . . , u − 1} を定義域とする Tbef ore の部分

は字句の種類を表す (k ∈ K)．また，写像 gs ，gk をそれぞれ

列を X ，Taf ter に関して，{j + 1, . . . , v − 1} を定義域とする

gs (t) = s，gk (t) = k と定義する．さらに，字句 t1 ，t2 におい

Taf ter の部分列を Y とする．このとき，(X ，Y ) の対を一致間て，gs (t1) = gs (t2) となるとき t1 = t2 とみなす．

部分列対と呼ぶ．この一致間部分列対を S として，一致間部分［Definition 3.6］（字句の種類） K には，一般的な字句解析

列対 S はそれを構成要素である部分列 X ，Y のうちいずれか器で定義される字句の種類に加えて，コメント，空白，タブ，の要素数は 0 になりえるが，双方の要素数が 0 にはなりえな

および改行文字も字句の種類として含まれる．また，K の部分

い．Tbef ore ，Taf ter の間で取得できるすべての一致間部分列対集合として以下を定義する．

に対して，Algorithm1 を実行することで，種類対応関係を取•W = { 空白，タブ，改行 }る．Algorithm1 は，部分列 X ，Y を入力として，種類対応関•C = { コメント }係を持つ字句対の列を出力する．上記の処理によって，Tbef ore•

P = K − (W ∪ C)

［Definition 3.7］（字句列） Vϕ が字句の集合であるような列

ϕ を，字句列とする．

4. 修正の分割手順
提案手法における，コミットに含まれる修正の分割手順は以下の四つになる．

の要素 xs と Taf ter の要素 yt の間に種類対応関係があるとき，

xs ↔ yt と表す．
ステップ 3：字句に行われた修正の分類
ステップ 2 の二つの対応関係を利用することで，Tbef ore，Taf ter において行われた修正を字句単位で特定できる．各字句の修正が追加，削除，変更のいずれであるかは以下の条件で
決定する．

—3—

Algorithm 1 種類対応関係の特定プログラムコードの修正：

コメントの修正：

フォーマットの修正：
修正後

修正前

Input: X ，Ypublic boolean method1(int var1){ public boolean method1(int var2){
if(var1==0){return false;
return true;//Comment}}
return false;}

Output: TP
pairposition ← 1
for all beforeToken ∈ VX doi ← pairposition
for i to |IY | doafterToken ← Y (i)if gv (beforeToken) == gv (afterToken) then

図 3 実験における修正箇所の色分け例

TP ← TP + ⟨beforeToken, afterToken⟩
pairposition ← i + 1

5. 1 実 験 方 法

break

著者らは実験の準備を以下の手順で行った．

end ifend forend for

手順 1

実験対象リポジトリにツールを適用する．

手順 2

入力として与えられたリポジトリから，一度のコミッ

トで二種類以上の修正が同時に行われたソースファイルを実験•データとして抽出する．

yj が追加 (yj ∈ VTaf ter )：手順 3∀xi ∈ VTbef ore [xi ̸⇔ yj ∧ xi ̸↔ yj ]•手法が特定した分類に従い色分けする．修正箇所の色分けの例
手順 1-3 で準備した実験データの各修正箇所に対して，被験(2)

xi が変更 (xi ∈ VTbef ore )：∃yj ∈ VTaf ter [xi ↔ yj ]実験データとするファイルに加えられた修正を，提案を図 3 に示す．

xi が削除 (xi ∈ VTbef ore )：∀yj ∈ VTaf ter [xi ̸⇔ yj ∧ xi ̸↔ yj ]
•

(1)

(3)

上記の判定の結果，追加，削除，および修正のいずれかが字句者に以下の二つのことを確認してもらった．

•

修正の範囲は正しいか•

修正の分類は正しいか

この二つがすべて正しいとき，提案手法による分割が正しいと判断した．また，正しくないと判断されたものに関しては，被験者に正しい範囲と分類を指摘してもらった．

t に対して行われている時，字句 t が修正された，という．こ5. 2 評 価 項 目のステップでは字句に対して行われた修正を修正 A，修正 B，

実験のデータ，および結果を以下の項目で評価した．

修正 C の三つに分類する．以下にある字句 t に対する修正を分

出力数 提案手法が特定した各種類の修正箇所の集合を H と類する条件を示す．

して，その要素数

修正 A

以下の二つの条件をすべて満たす

出力正解数

H の内，分割が正しいとされた修正箇所の集合を•

gv (t) ∈ W

I として，その要素数•t が属する一致間部分列対 S(S = (X, Y )) について，

正解数 被験者に修正された修正箇所の修正後の集合を J とし

VS = VX ∪ VY としたとき，∀c ∈ VS [gv (c) ̸∈ P ] が満たされる
修正 B

gv (t) ∈ C

修正 C 以下二つの条件のいずれかを満たす•

gv (t) ∈ P•

t が属する一致間部分列対 S(S = (X, Y )) について，

VS = VX ∪ VY としたとき，∃c ∈ VS [gv (c) ∈ P ] ∧ gv (t) ∈ W
ステップ 4：コミットの分割
ステップ 3 で行った修正の分類に基づいてコミットの分割を行う．ソースファイルに対する修正は修正 A，B，C の三種類にまとめられ，分割によって一つのコミットが最大三つのコミッて，I ∪ J の要素数
適合率，再現率|I|∗ 100，
|H|

|I|
∗ 100
|I ∪ J|

5. 3 実 験 結 果
各被験者は 5 つの実験データに対して実験を行った．結果は
表 1 のようになった．表の行は各被験者を表し，列は評価項目を表している．表 1 における総合の項目の適合率は約 67%となり，再現率は約 72%となった．

トに分割される．

5. 実

験

表1

実験結果

出力数

出力正解数 適合率

再現率

1

177

354

141

39.83

79.66

本研究では提案手法を実装したツールを用いて，修正の分類

2

36

37

32

86.49

88.89

の正しさを確認する評価実験を行った．実験の対象は著者らの

3

115

117

112

95.73

97.39

4

490

375

307

81.87

62.65

総合

818

883

592

67.04

72.37

研究室で開発されたいくつかのソフトウェアであり，実験は対象ソフトウェアの開発者の協力のもと行った．

被験者 正解数

—4—

修正後
……
@Override
public Set<PDGEdge> getAllBackwardElementDataEdge() {return getBackwardElementDataEdge();}

提案手法が修正箇所とみなす範囲：
被験者が修正箇所とみなす範囲：
修正前……
@Override
public Set<PDGEdge> getAllBackwardElementDataEdge() {return getBackwardElementDataEdge();
}
……

……

対応する行と被験者は認識

図4

6. 議

@Override
public boolean isLabel() {return false;}……

分類が誤りとされた例

論

6. 1 分類がうまくいかなかった例
実験において行った分類の内，分類がうまく行えなかった例
について述べる．

より精度の高い判定を行うには被験者ごとの判定基準を加味する必要がある．

7. 関 連 研 究
Fluri らは，ソースコードに加えられた修正をその意味に応じ

図 5. 3 のような分類が，被験者によって誤りとされることがて自動的に分類する手法を提案している [10]．この手法はソー多かった．図における強調箇所は修正箇所であり，提案手法がスコードから抽象構文木を構築し，それらを比較することで，修正箇所とみなした箇所と，被験者が認識した修正箇所を重ね修正が行われた箇所を特定する．また，それぞれの修正内容にて示している．最長共通部分列を用いた方法では修正されたと応じて，特定した修正を文献 [11] で述べられている定義に従っみなされる字句数が最小となるように修正箇所を求めるが，提て分類している．

案手法が特定した修正箇所における修正字句数は 23 であるの

Kawrykow と Robillard はソースコードに加えられた修正のに対して，被験者の認識した修正箇所における修正字句数は 24

内，リポジトリマイニングを行う上で有用ではないものを特定であり，提案手法が特定した修正箇所における修正字句数の方する手法を提案している [12]．彼らの手法では，ソースコードが少ない．これにより提案手法が特定した修正箇所と，被験者に加えられたプログラムコードの修正の内，変数名の変更などが認識した修正箇所にずれが生じたと考えられる．

に伴う修正を “表面的な”変更とし，これらをリポジトリマイニ

6. 2 被験者による判断基準の違い

ングの対象に加えることは有用ではないとしている．

5. における表 1 の値に関して考察する．被験者 4 に対する実これらの手法は提案手法と同様に，ソースコードに加えられ験の結果，正解数が 490 であるのに対して，出力数は 375 と大た修正を分類している．しかし，提案手法はコミットを分割す

きな差が生じた．これは図 5(c) のような例が原因である．複数ることでフォーマットの修正やコメントの修正を取り除き，プの字句がまとまって追加されたという修正に対して，提案手法

ログラムコードの修正のみを抽出できる点で，既存の修正を分

はそれらを一つのまとまったプログラムコードの修正と判定し類する手法とは異なる．

ている．それに対して被験者は追加された字句の内，空白，タHayashi らはソースコードの編集履歴のリファクタリング手

ブ，改行文字の追加をフォーマットの修正と判定している．こ法を提案し，その自動化ツールを統合開発環境 Eclipse のプラれにより正解数と出力数に大きな差が生じた．また，被験者 1

グインとして開発している [13]．Hayashi らの手法は開発者がに対する実験結果においても，正解数，出力数に大きな差が生行った編集操作を自動的に記録し，その操作に対して順序の入じた．これは図 5(a) のよう例が原因で，提案手法が複数の細かれ替えや，統合，取り消しを可能にしている．異なる目的を持い修正があると判定した箇所を，被験者は一つのまとまった修

つ編集操作が混在した履歴についても，編集操作の入れ替えや正であると判定したためである．このような提案手法による判統合によってそれぞれの目的ごとに編集操作をまとめることで，定の基準と被験者の判定基準の違いが，被験者 1 および被験者同じ目的で行われた編集操作を一つの修正としてまとめてリポ

4 の適合率及び再現率の低下に大きな影響を与えている．しかジトリにコミットすることを可能にしている．Hayashi らの手しながら，図 5(b) のように，被験者 3 は提案手法が特定する法がソースコードに対する編集履歴の再構築を行うのに対し，修正箇所を正しいと判定している．すなわち被験者 3 は提案手

提案手法は版管理システムに変更を反映させて得られた開発履法に近い判定基準で修正箇所の判定を行っていたといえる．し歴の再構築を行っているという点で異なる．

たがって，表 1 における被験者 3 の結果をみると，適合率，再開発履歴に出現する大規模な修正に関する調査もいくつか行

現率の双方ともに他の被験者と比較して高い値となっている．

われている．Hattori らが行った調査によると，修正は五個以それに対して，図 5(c) のように修正箇所を判定した被験者 4

下のファイルに対して変更を加えるものがほとんどであるが，は，表 1 においても適合率と再現率の値は被験者 3 に比べて低一部 100 を超えるファイルに対して変更が加えられるコミット

くなっている．このように被験者ごとに判定基準が異なるため，が存在することを指摘している [9]．Hindle らの報告によれば，—5—

基づいて，コミットを分割する手法を提案した．
提案手法
の判定

if (originalStatement instanceof VariableDeclarationStatementInfo) {return true;}
フォーマットの修正2つとプログラムコードの修正4つが混在している

被験者1
の判定

if (originalStatement instanceof VariableDeclarationStatementInfo) {return true;}
まとめて1つのプログラムコードの修正

また二つの評価実験を行い，分類の正しさを評価する実験では，適合率は約 67%，再現率は約 72%となった．
今後の課題は以下の二点である．

•

修正の分類方法を改善することで，より開発者の認識に近い分類を行うようにする．

•

実際のリポジトリマイニング手法を，提案手法の適用前

後のリポジトリに対して適用し，その結果の変化を確認する．

(a) 被験者 1

謝辞 本研究は，日本学術振興会科学研究費補助金萌芽研究(課題番号：24650011)，若手研究 (A)(課題番号：24680002) の助成を得た．
提案手法の判定

for (final RetrievedCloneSetInfo cloneSet : cloneSets.values()) {if (cloneSet.getCount() > 1) {final long cloneSetId = cloneSet.getId();for (final RetrievedBlockInfo block : cloneSet.getAllElements()) {block.setCloneSetId(cloneSetId);}
result.add(cloneSet);}
まとめて1つのプログラムコードの修正

被験者3
の判定

for (final RetrievedCloneSetInfo cloneSet : cloneSets.values()) {if (cloneSet.getCount() > 1) {final long cloneSetId = cloneSet.getId();for (final RetrievedBlockInfo block : cloneSet.getAllElements()) {block.setCloneSetId(cloneSetId);}
result.add(cloneSet);}
提案手法の判定と同じ(b) 被験者 3

提案手法
の判定

coll.insert(new BasicDBObject().append("_id", EVENT10_OID).append("eventId", EVENT10_OID.toString()).append("eventName", "testeventname").append("eventDate", SDF.parse("2014/01/01 00:00:00")).append("ticketStartDate", SDF.parse("2013/12/01 00:00:00")).append("description", "testevent").append("promoterId", "igaki").append("totalSeats", seats));

まとめて1つのプログラムコードの修正

被験者4
の判定

coll.insert(new BasicDBObject().append("_id", EVENT10_OID).append("eventId", EVENT10_OID.toString()).append("eventName", "testeventname").append("eventDate", SDF.parse("2014/01/01 00:00:00")).append("ticketStartDate", SDF.parse("2013/12/01 00:00:00")).append("description", "testevent").append("promoterId", "igaki").append("totalSeats", seats));
フォーマットの修正10つとプログラムコードの修正10つが混在している(c) 被験者 4

図 5 被験者による判定基準例

ビッグコミットが起こる要因として，本流から枝分かれして開発されていたソースコードを本流へ合流させること (merge) や，
フォーマット変更や不要になったコードの削除などを挙げている [14]．

8. あ と が き
本研究では，コミットに含まれる修正を分類し，その分類に

文

献[1] 松下 誠，“ソフトウェア工学の新潮流 (1) リポジトリマイニ
ング，” ソフトウェアエンジニアリング最前線 2009，pp.21–24，
Sep. 2009．
[2] 林晋平，佐伯元司，“リファクタリング支援に用いる知識抽出のためのソフトウェアリポジトリの解析，” 電子情報通信学会技術研究報告，vol.106，no.16，pp.1–6，2006．
[3] M. Askari and R. Holt, “Information Theoretic Evaluation of Change Prediction Models for Large-scale Software,”Proc. of the 3rd International Workshop on Mining Software
Repositories, pp.126–132, May 2006.
[4] H. Kagdi, S. Yusuf, and J.I. Maletic, “Mining Sequencesof Changed-Files from Version Histories,” Proc. of the 3rdInternational Workshop on Mining Software Repositories,
pp.47–53, May 2006.
[5] H. Kagdi, J.I. Maletic, and B. Sharif, “Mining Software
Repositories for Traceability Links,” Proc. of the 15th International Conference on Program Comprehension, pp.145–
154, June 2007.
[6] A.E. Hassan, “The Road ahead for Mining Software Repositories,” Frontiers of Software Maintenance, pp.48–57, Sep.
2008.
[7] 小林隆志，林晋平，“データマイニング技術を応用したソフト
ウェア構築・保守支援の研究動向，” コンピュータ ソフトウェア，
vol.27，no.3，pp.13–23，Aug. 2010．
[8] T. Zimmermann and P. Weißgerber, “Preprocessing CVS
Data for Fine-grained Analysis,” Proc. of the 1st International Workshop on Mining Software Repositories, pp.2–6,
May 2004.
[9] L.P. Hattori and M. Lanza, “On the Nature of Commits,”
Proc. of the 23rd International Conference on AutomatedSoftware Engineering Workshops, pp.63–71, Sep. 2008.
[10] B. Fluri, M. Wuersch, M. PInzger, and H. Gall, “Change
Distilling: Tree Diﬀerencing for Fine-Grained Source CodeChange Extraction,” IEEE Trans. on Software Engineering,vol.33, no.11, pp.725–743, Nov. 2007.
[11] B. Fluri and H.C. Gall, “Classifying Change Types for Qualifying Change Couplings,” Proc. of the 14th International
Conference on Program Comprehension, pp.35–45, June
2006.
[12] D. Kawrykow and M.P. Robillard, “Non-Essential Changes
in Version Histories,” Proc. of the 33rd International Conference on Software Engineering, pp.351–360, May 2011.
[13] S. Hayashi, T. Omori, T. Zenmyo, K. Maruyama, and M.
Saeki, “Refactoring Edit History of Source Code,” Proc. ofthe 28th International Conference on Software Maintenance,
pp.617–620, Sep. 2012.
[14] A. Hindle, D.M. German, and R. Holt, “What Do Large
Commits Tell Us?: A Taxonomical Study of Large Commits,” Proc. of the 5th International Working Conferenceon Mining Software Repositories, pp.99–108, May 2008.

—6—