*** SCM Paper Court Trial Tuesday 1 May 2007***

Article: A State-of-the-art Survey on Software Merging
Sherwood Pengel, Petter Hoglund and Daan van Dijk

Attack #1: The author talks about state based, change based and 
operation based merging and the difference between them but doesn't 
provide explicit examples of change-based merges that aren't 
operation-based merges. The author doesn't clarify the difference with 
examples.

Defense: From the article we can understand that two-way merges are 
state-based and three way merges are change-based. The author describes 
that operation based merging takes place when, in stead of comparing the 
bare changes, these changes are modelled into (mapped unto) explicit 
operations on the revisions and the evolution operations between 
different revisions are used in the merge. The author mentions operation 
based merging as a form of change based merging.

Attack #2: When the author talks about using evolution operations in 
operation based merging, how does one determine the different possible 
evolution operations? This is not clear from the article.

Defense: The autor stated that the notion of operation based merging is 
a generally accepted theory but also mentioned that the way it is 
applied and more specific the granularity and set of operations are 
defined by which development environment and programming language are 
used. The developer of the development environment needs to make sure 
the development environment is able to distinguish different evolution 
operations.

Attack #3: The author states that for reducing conflicts one should make 
important new changes in separate branches and that the number of 
branches should be as small as possible. The author then continues to 
say that branches should only be used when parallel development is 
necessary. This seems contradictory. It's as if the author is saying not 
to improve too much.

Defense: The author is giving guidelines to reduce conflicts. The author 
stresses the fact that creating a branch is a significant event. 
Implementing a lot of changes at a time is fine as long as the necessary 
amount of extra branches is kept at a bare minimum (as much as is needed 
for parallel development). In other words: do not unnecessarily create 
branches for changes that could be kept in the same branch. Bugfixing 
can be done on the main development line.