> > 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 conflicting files, > > and do the above dance for the developer? > > 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 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), especially given our ample real-world experience that the current model does not scale. > What if Cadmium provided a pull_merge_recommit command that combined > the steps on the client side? This would be an improvement, but still painfully slow for those who are remote. (I encourage those of you in MPK to try working with a remote ON gate via Mercurial -- it is excruciatingly slow.) > Or what if there was a webpage which showed how many people have tried > and failed to do pushes recently, so you could tell when the gate is > idle? Ick. -- meem
