On Fri, Mar 28, 2008 at 11:58:34AM -0400, Richard Lowe wrote: > Danek Duvall <danek.duvall at sun.com> writes: > > > On Fri, Mar 28, 2008 at 09:50:08AM -0500, Dean Roehrich wrote: > > > >> I'm concerned that if a push comes in while a pull is in progress then the > >> pull may see the pushed items before the push transaction is closed (or, > >> more > >> importantly, before the transaction is aborted&rolled-back). > > > > There is a race here. Changeset data may be delivered to pullers before > > it's fully "available" -- that is before the manifest and changelog files > > have been written. They won't be able to see that data with the standard > > tools, but they will be able to retrieve it. > > > > Looking through the code, I don't see how that would be the case. Do > you have a link? > > There is a race in the period between the changelog being written, and > the transaction possibly being aborted, which is what we were talking > about with locking v. separate repo. > > I'm not certain if a pull that started before that hypothetical lock > was written could pull a changeset created after it began, however, > but as best as I can tell it would have to be a complete changeset.
Here's an interesting exercise: $ hg init r1-ds $ hg clone r1-ds r1 $ hg clone r1 r2 Add the following to r1/.hg/hgrc: -----cut--- [hooks] pretxnchangegroup.Z_propagate = cd ../r1-ds; hg pull ----cut--- $ cd r2 Commit something, and push. The r1-ds repo won't be able to pull the changeset from r1 with the transaction incomplete. Change r1/.hg/hgrc to be this instead: -----cut--- [hooks] pretxnchangegroup.Z_propagate = hg push ----cut--- $ cd r2 Commit something, and push. The r1 repo was able to push to r1-ds, with the transaction incomplete. Dean
