On 2010-03-10, at 8:41 PM, Andreas Raab wrote:

>> But I think we're talking past each other. It really is better, from a package-history point of view, to commit regardless of what else is in the repository, and merge afterward.
> 
> Wow. I'm amazed to hear you say that. Package history is specifically one of the main reason why I prefer merging before commit. For example, let's look at the package history of the System package in current trunk:
>> 

[snip ascii graph]

> (I find this impossible to understand even *with* the ascii graph)
> 
> Let's assume I need to isolate a change, when it happened to either verify if it was in a shipped product version or not. Look at the last line in the above: If you're going down you might expect that System-dtl.283 is below ("before") System-nice.284. But it's not. It's actually *eight* lines on top of it. So is System-ar.284 merged by System-nice.285. In other words there is no consistency in the graph - you cannot assume that something that happened before something else appears below it. Now let's look at a nice simple plain merge-before-commit version history:

Ok, I get it. You like to merge first because it generates *simpler* package history. I like to merge afterwards because it generates more *complete* package history.  

When you merge first, you lose the state of the package you were about to commit. When you save first, that information is available for trouble shooting later. If you have to go back and isolate a problem, you can tell whether it was introduced by changes a developer made while coding or during a merge. In either case it's easier to understand the set of changes, because they're a coherent unit - either a unit of development by a single developer, or a merge - rather than a mixture of several sets of changes. 

But yeah, it's easier to track down a single change when the package history is linear. 

> Nothing personal, Colin, I really appreciate what you guys have been doing but I don't see how one could possibly say that merge-after-commit is better for package history. The precise opposite seems to be true.

No worries. As I said in another post, I'm fine with making it a preference.

I think this is essentially a UI problem - bushy history graph is too hard to understand the way it's presented. The "best" fix would be to have better tools for examining package history and differences between package versions, but that's a big project. In the meantime, the preference will let us work around the problem in our respective ways.

Colin