Danek Duvall wrote:
> On Thu, Aug 02, 2007 at 03:08:59PM -0700, Stephen Lau wrote:
>
>> Mike Kupfer wrote:
>>> Slides 3, 10: I'm not a fan of random artwork unless there's some
>>> relevance to the material on the slide. It's okay to just leave the
>>> space blank. (Slide 13, OTOH, is great.)
>>
On Thu, Aug 02, 2007 at 03:08:59PM -0700, Stephen Lau wrote:
> Mike Kupfer wrote:
> > Slides 3, 10: I'm not a fan of random artwork unless there's some
> > relevance to the material on the slide. It's okay to just leave the
> > space blank. (Slide 13, OTOH, is great.)
>
> They are supposed to b
Bill Sommerfeld writes:
> On Thu, 2007-08-02 at 15:02 -0600, Jim Walker wrote:
>> Will we need to "lock" the Hg gate for big putbacks like we do now
>> with the Teamware gate?
>
> Yes.
>
> The reason for locking the gate for large putbacks is to lock out small
> conflicting changes which would re
On Thu, 2007-08-02 at 15:02 -0600, Jim Walker wrote:
> Will we need to "lock" the Hg gate for big putbacks like we do now
> with the Teamware gate?
Yes.
The reason for locking the gate for large putbacks is to lock out small
conflicting changes which would require a merge/build/test cycle.
> "stevel" == Stephen Lau writes:
stevel> They are supposed to be mercury and cadmium
Aha!
stevel> I can take 'em out if people want. I just had some blank space
stevel> to fill and thought it might be neat.
Sure, keep 'em. We just need to mention what they are when we get to
those slide
Mike Kupfer wrote:
> Slides 3, 10: I'm not a fan of random artwork unless there's some
> relevance to the material on the slide. It's okay to just leave the
> space blank. (Slide 13, OTOH, is great.)
They are supposed to be mercury and cadmium; but perhaps that isn't
obvious. :) I can take 'em
Jim Walker wrote:
> Mike Kupfer wrote:
>> Jim> - Why don't we have an external clone? Is the readable
>> Jim> clone/writable gate not needed anymore?
>>
>> stevel> Yup, it's not needed anymore.
>>
>> The last I heard Stephen Hahn talk about this, he liked the idea of
>> having a semi-stable nightly
>> Will we need to "lock" the Hg gate for big putbacks like we do now
>> with the Teamware gate?
>
> Yes.
>
> The reason for locking the gate for large putbacks is to lock out small
> conflicting changes which would require a merge/build/test cycle.
But we're talking about two different things, I
> Jim> I was talking with Mark Nelson about the clone, and he mentioned
> Jim> that in the reasons they have an active clone:
> [...]
> Jim> 1. reduces locking issues (teamware issues)
> Jim> 2. more stable than gate (ie. changed only once a day)
> Jim> 3. reduces traffic on gate (ie. pulls are do
Mike Kupfer wrote:
> [added Mark to the cc list]
>
>> "Jim" == Jim Walker writes:
>
> Jim> I was talking with Mark Nelson about the clone, and he mentioned
> Jim> that in the reasons they have an active clone:
> [...]
> Jim> 1. reduces locking issues (teamware issues)
> Jim> 2. more stable t
> "Jim" == Jim Walker writes:
Jim> 3. reduces traffic on gate (ie. pulls are done most of the time)
Mike> Is point 3 related to system-level contention issues,
Jim> Yep. If I/O contention isn't an issue then 3 doesn't apply to Hg.
AFAIK, we don't have much in the way of measurements in thi
Mike Kupfer wrote:
> Jim> - Why don't we have an external clone? Is the readable
> Jim> clone/writable gate not needed anymore?
>
> stevel> Yup, it's not needed anymore.
>
> The last I heard Stephen Hahn talk about this, he liked the idea of
> having a semi-stable nightly snapshot--something that
[added Mark to the cc list]
> "Jim" == Jim Walker writes:
Jim> I was talking with Mark Nelson about the clone, and he mentioned
Jim> that in the reasons they have an active clone:
[...]
Jim> 1. reduces locking issues (teamware issues)
Jim> 2. more stable than gate (ie. changed only once a da
Slides 3, 10: I'm not a fan of random artwork unless there's some
relevance to the material on the slide. It's okay to just leave the
space blank. (Slide 13, OTOH, is great.)
Slide 6: I would change the access control bullet to "Different access
control model", since I think that's the high-orde
> "stevel" == Stephen Lau writes:
Jim> Slide 4:
Jim> - We need to plug training into the equation. We won't
Jim> be successful unless people know how to use the new tools.
stevel> Yeah - this is only half (if that) of the KTD so far. The
stevel> training comes in the second half (e.g.: the
Steve,
Here's a few comments...
- You may want to be less hard on Teamware and remove:
slide 1: "teamware is dead, long live mercurial"
slide 11: "made Teamware suck less"
Some people may take offense
Slide 3:
- I would list specific reasons why we are changing
to Mercurial and not just leave it
Jim Walker wrote:
> Steve,
>
> Here's a few comments...
>
> - You may want to be less hard on Teamware and remove:
> slide 1: "teamware is dead, long live mercurial"
> slide 11: "made Teamware suck less"
> Some people may take offense
Sure
> Slide 3:
> - I would list specific reasons why we are
Here's what I have so far if people want to start reviewing it. I'll
continue to work on them this morning - but thought I might as well send
out what I have.
Feedback appreciated.
and many many thanks to Mike for his work on the outline - that made it
considerably easier to work on this.
on
18 matches
Mail list logo
