I'm sure most every ON developer has now suffered through the horrible
experience of being ready to integrate and doing a push only to discover
someone else has beaten them to the punch. Once this happens, we must go
through the mechanical and tedious process of
hg pull
hg merge
Peter Memishian writes:
> I was still fuming about this experience at lunch when Jonathan Adams
> raised an alternative: given that the above is entirely mechanical, why
> can't the gate do it for us? That is, why cant the hg push logic see that
> there are other changesets but that none of them h
Mark J. Nelson writes:
> > usr/src/tools/lintdump/Makefile
> >
> > 33-34: already the default in Makefile.master; shouldn't be needed.
>
> I had imagined that any changes made here were done to silence protocmp,
> but I'll ask Rainer.
I can't find in my notes why I added this (probably the w
Quoth Peter Memishian on Fri, Feb 06, 2009 at 01:01:57AM -0500:
> I was still fuming about this experience at lunch when Jonathan Adams
> raised an alternative: given that the above is entirely mechanical, why
> can't the gate do it for us? That is, why cant the hg push logic see that
> there are
> > I was still fuming about this experience at lunch when Jonathan Adams
> > raised an alternative: given that the above is entirely mechanical, why
> > can't the gate do it for us? That is, why cant the hg push logic see that
> > there are other changesets but that none of them have conflic
Quoth Peter Memishian on Fri, Feb 06, 2009 at 02:22:21PM -0500:
> > It seems to me that there is some value to telling the user which files
> > were changed, so I think we should avoid doing this on the gate.
>
> As per my earlier email, this was also the case with Teamware. I'm not
> aware of
I broadened this to gatekeeper, because I'm hoping that one or more
members of the core team will chime in.
I don't think we want to literally automate the pull, merge, commit,
recommit cycle. Anything we do, in that regard, will still be subject
to repeated collisions.
The need for this cycl
> "Jim" == James Carlson writes:
Jim> it'd be nice if Mercurial could itself do something to support the
Jim> "changesets with non-overlapping sets of files don't actually
Jim> require merge" model
The model that Matt Mackall endorses is one where someone pulls from the
repos that have the f
> > As per my earlier email, this was also the case with Teamware. I'm not
> > aware of anyone ever running into problems (actual counterexamples
> > welcome). I've had enough hand-wringing about theoretical merge problems
> > (and that could be easily remedied were they to occur), especiall
> "meem" == Peter Memishian writes:
David> It seems to me that there is some value to telling the user which
David> files were changed, so I think we should avoid doing this on the
David> gate.
meem> As per my earlier email, this was also the case with Teamware.
Yes, but that's sort of the
Quoth Mark J. Nelson on Fri, Feb 06, 2009 at 04:33:48PM -0700:
> I think the primary argument against allowing merge changesets in
> Mercurial is that, when SCCS merge deltas were allowed in Teamware, they
> resulted in reduced signal to noise in the metadata. I don't think, if
> merge changese
Oops, forgot to respond to something...
> "meem" == Peter Memishian writes:
meem> (I encourage those of you in MPK to try working with a remote ON
meem> gate via Mercurial -- it is excruciatingly slow.)
Are you using NFS or ssh? Yes, using Mercurial and NFS for ON is
prohibitively slow. W
David Bustos wrote:
> Quoth Mark J. Nelson on Fri, Feb 06, 2009 at 04:33:48PM -0700:
>> I think the primary argument against allowing merge changesets in
>> Mercurial is that, when SCCS merge deltas were allowed in Teamware, they
>> resulted in reduced signal to noise in the metadata. I don't th
Mark> If we keep our strict requirement, then we're looking at one of two
Mark> different approaches: live with the cycle, and automate it as much
Mark> as possible to ease developer pain...
That's what I want to see. As we were discussing on the phone just now,
whereas now when a push is blocked
> David> It seems to me that there is some value to telling the user which
> David> files were changed, so I think we should avoid doing this on the
> David> gate.
>
> meem> As per my earlier email, this was also the case with Teamware.
>
> Yes, but that's sort of the point. With Teamwar
> > "meem" == Peter Memishian writes:
>
> meem> (I encourage those of you in MPK to try working with a remote ON
> meem> gate via Mercurial -- it is excruciatingly slow.)
>
> Are you using NFS or ssh? Yes, using Mercurial and NFS for ON is
> prohibitively slow. With ssh, my experie
> "meem" == Peter Memishian writes:
meem> (I encourage those of you in MPK to try working with a remote ON
meem> gate via Mercurial -- it is excruciatingly slow.)
Mike> Are you using NFS or ssh?
meem> NFS.
That's a large part of your problem. Use an ssh URL. We may still
need to address
> Mark> If we keep our strict requirement, then we're looking at one of two
> Mark> different approaches: live with the cycle, and automate it as much
> Mark> as possible to ease developer pain...
>
> That's what I want to see. As we were discussing on the phone just now,
> whereas now whe
> We should also explore moving stuff out of ON that doesn't really need
> to be there.
This obviously comes with its own overhead, since the code has to live
somewhere else (which has to be maintained), and there are often
interdependencies on interfaces that are not themselves stable. In oth
Mark J. Nelson wrote:
> I broadened this to gatekeeper, because I'm hoping that one or more
> members of the core team will chime in.
>
> I don't think we want to literally automate the pull, merge, commit,
> recommit cycle. Anything we do, in that regard, will still be subject
> to repeated c
20 matches
Mail list logo
