[PATCH STABLE RFC] transplant: avoid a dirstate race when transplanting multiple changesets

[Matt Mackall]

On Wed, 2011-01-26 at 09:18 -0500, Greg Ward wrote:
> On Tue, Jan 25, 2011 at 5:48 PM, Matt Mackall <mpm at selenic.com> wrote:
> > On Tue, 2011-01-25 at 09:18 -0500, Greg Ward wrote:
> >> # HG changeset patch
> >> # User Greg Ward <greg-hg at gerg.ca>
> >> # Date 1295964871 18000
> >> # Branch stable
> >> # Node ID f501e673e1188511f3bd22959dd8ed693d458011
> >> # Parent  d0e0d3d43e1439d63564ab4dddfe0daa69ae2d86
> >> transplant: avoid a dirstate race when transplanting multiple changesets
> >> (issue2264, issue2516)
> >
> > Queued for stable with title fixed to be robot-legible.
> 
> Great, thanks!  However, I may have thought of a better way to fix it.
>  Here's my logic: the problem is that doing multiple commits in a row
> in the same process is prone to dirstate races.

Hmm..

> Specifically, take the loop I added to transplant:
> 
> +        for fn in files:
> +            repo.dirstate.normallookup(fn)

So usually after update or commit, we mark a file in state 'normal',
which records the current time in the dirstate.

If the file then gets modified in the same second without the size
changing, then the next commit -in the same process- could miss the
change.

But if we actually write out the dirstate, we blank out the timestamp of
any files where timestamp matches a window around the current second,
which is like the normallookup state but only for files inside the risk
window.

See the big comment in dirstate.write on this topic. We should probably
to try to match this logic internally without losing the timestamp on
all files.

-- 
Mathematics is the supreme nostalgia of our time.