On 3/10/2010 9:37 PM, Colin Putney wrote:
> 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.

I see what you're saying. I think it partly depends on what you usually 
need to do with package history - for me, most of the time the question 
is when a change was introduced, whether it was the result of a merge or 
development is secondary.

Here's an idea for MC2: Use UTC time stamps and order the history 
strictly by time. Given non-trivial package histories that is the one 
that would be most useful to me. Alternatively, colorize branches.

> 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.

Pretty much all of it, yes. Basically it's an exercise in optimizing 
various workflows.

Cheers,
   - Andreas