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 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.
I don't think "that's how it was with Teamware" is a compelling argument for cementing a less than best practice. Reduced productivity might be, but I'm not aware of our experience that the current model doesn't scale. Perhaps I haven't been paying close enough attention to this list. Have many people been complaining? Is there a bug report with many call records? > > 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.) So you're saying that the cost is dominated by the repeats and not the hg commands? > > 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. Perhaps I'm stunned by your eloquence, but I don't understand. Do you not think that would be complete, or do you not think it would be reliable? If the cost is indeed dominated by the number of cycles, then I believe this would attack the root of the problem. David
