[squeak-dev] Re: The Trunk: Monticello-ar.379.mcz
siguctua at gmail.com
Thu Mar 11 06:06:57 UTC 2010
I am with Colin's choice.
Consider my workflow: i done doing something and decided to commit,
take a nap, go watch TV, or do anything
i need. So, when i press commit, i mean: i am done for today, save my
work, and let me do something else.
But going Anreases workflow i will be unable to commit before i megre
my stuff with somebody's else, which may take
from a few minutes up to multiple hours of work.
On 11 March 2010 07:55, Andreas Raab <andreas.raab at gmx.de> wrote:
> 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
>> 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
> - Andreas
Igor Stasenko AKA sig.
More information about the Squeak-dev