Hi,

1. Are there any changes conflicting with my own?
2. If there are no direct conflicts (i.e. a merge worked), will the
   "baseline" changes combined with my own conflict? (i.e. are there
   implicit conflicts?)
3. Do all the tests pass after the merge?
4. How quickly can I get my changes published before someone else
   publishes and I have to merge again :-)

To track / understand other people's changes, mostly for the purpose
of resolving conflicts, I need information on the version that I'm
merging with including all the versions in between. So, something like
a summary of all the version comments (collected) and a summary of all
the changes (that I can drill into if I need to).

I suppose the kind of questions depend a lot on the way we work?

My 2 cents
Otto

• When the version to be merged into the trunk is on a branch which I
  already did merge a couple of versions earlier I want to have to see/think
  about only those changes that are new (i.e. the changes between the version
  last merged and the current version to be merged and not all changes
  between the current version to be merged and the trunk version to be merged
  into)

e.g.

1.0 -> 2.0 -> 3.0 -> 4.0 -> 5.0 -> 6.0 -> 7.0  Trunk
\                /            / ?? questions asked here
\              /            /
-> 2.1 -> 2.2 -> 2.3 -> 2.4  Branch

The branch version 2.2 has already been merged into trunk version 5.0 some
time earlier.
Therefore I'd like to merge only the changes between 2.2 and 2.4 into 7.0.
I don't know what Pharo does but VisualWorksdisplays all changes between
2.4 and 7.0 while giving additional information about the last common
version which is determined to be 2.0 because previous merges are not
considered.
This forces me to think about how to merge all changes up to version 2.2
once again.
We fixed that in our tools, of course (in VW 7.6), offering an additional
merge option which only merges the changes since a user selected common
version.

Regards

Thorsten

Am 23.11.2011 um 16:57 schrieb Stéphane Ducasse:

Hi,

Besides the questions you asked, I would be interested in how changes are grouped together. In particular, when merging the work of multiple authors with changes stacked on top of each other, I would like to be able to group the differences in different ways. For example:

• I would like to be able to group them by author, or
• I would like to group them by time (such that commits on different packages get closer together when they are committed closer in time).

Cheers,
Doru

On 23 Nov 2011, at 16:57, Stéphane Ducasse wrote:

--
www.tudorgirba.com

"Don't give to get. Just give."

Hi all,

A little late, but I still wanted to react to these questions.

Besides the obvious question on 'what functionality does the change fix/add/remove?', I often find myself navigating and browsing code to answer the following questions:

• Does the change remain confined to a module (this can be a package, class, …) or is it crosscutting ?
• What parts of the system are directly using the changed behavior? Is it a central part of the system with many dependents?
• Who was the owner of the code that was changed? Should another developer review these changes (i.e. the original author whose code was adapted) ?
• If the change is a refactoring, were all appropriate parts refactored and no inappropriate ones included? Are there other packages that would need to change as well to incorporate this change?
• Does the code (partially) reinvent the wheel? In essence: does it introduce code duplication or does it implement parts that are reimplementations of existing parts in the code base or existing libraries?
• How about the unit tests? Was there a new test? Were they adapted? Is the code in this change covered adequately ?

I assume the verification of coding conventions, unit testing, etc… as a step of the integration process as well.

I should also note that, in our case, every developer needs to integrate his work in the trunk himself. A first check is therefore done by the developer who is merging his changes in the trunk. This change in the trunk is afterwards verified with the questions above. This means that, at that time, problems related to parallel changes are practically non-existant (i.e. the developer who integrates needs to deal with those directly). Daily coordination amongst developers also reduces the possibility on conflicting parallel changes. Such a single branch development is feasible for us because we work with a single software version and excluding changes from the trunk is a very uncommon decision (bad changes need to be corrected appropriately instead of simply left out).

best regards,
Johan

On 27 Nov 2011, at 20:45, Tudor Girba wrote:

tx :)
On Dec 3, 2011, at 11:23 AM, Johan Brichau wrote: