At what point does the push model degrade?
Peter Arrenbrecht
peter.arrenbrecht at gmail.com
Fri Nov 16 13:24:22 CST 2007
On Nov 16, 2007 7:26 PM, <Ezra.Smith at bentley.com> wrote:
> Fair enough, but we're transitioning from CVS, where revisions are on a per-file basis. Right now it's an extremely rare situation where I can pull the latest revision of a specific file, merge my changes in, and try to push...only to find that someone else has done the same thing with the same file. On the other hand, I see it as quite likely that I'll pull the latest changes in a Mercurial repository, do my merge, and try to push...only to find that someone has pushed something unrelated to my file, but has still changed the tip and forced me to merge again.
So essentially you're saying that most of the pushes would, in fact,
be trivial automated merges, right? Then could you not try a model
where you have a central, automated pusher job that is fed by a queue?
This queue could be a folder full of bundle files, which developers
put there, or else a periodical scan of per-developer central repos
for incoming changes (that might be a size issue, though). The job
would reject any non-automatic merges and inform the affected
developer.
-peo
More information about the Mercurial
mailing list