> > 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.
It seems I wasn't explicit enough. As I stated, we have more than a decade of operational experience with Teamware and we never to my knowledge hit the issue you raised. Further, even if we did hit the issue, the current model we use with Mercurial would also hit it, because no one can do a full retest after a pull/merge/commit/recommit cycle since if they did they'd open the window too wide to ever be able to integrate. > 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? This issue has come up repeatedly, both in hallway conversations and in TOIs. I've also received offline replies to my initial post here saying roughly "thank you, this is driving me crazy too"; I'll let those people make themselves known if they choose to. If folks want a bug filed, fine. > > > 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? I'm saying that running that cycle of commands takes several minutes to do if there's no recently-sync'd remote clone, and by that time someone else may have integrated and forced you around the merry-go-round again. We are wasting valuable developer time in integration spin-loops. > > > 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. It's a hackaround which adds more complexity and does not solve the problem at the root. We need to simplify the integration process, not add more steps. -- meem
