[Python-Dev] Workflow proposal

[Dirkjan Ochtman]

On Wed, Mar 23, 2011 at 12:39, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> Just as an aside, and I might be wrong. But reading through what strip
> does, (and from my knowledge of the disk layout) it can't actually be
> atomic. So if you kill it at the wrong time, it will have corrupted your
> repository.
>
> At least, that is from what I can tell. Which is that it has to rewrite
> each file history to omit the revisions you are stripping, and then
> rewrite the revision history to do the same. It would be possible to be
> 'stable' if you wrote a write-ahead-log and did all the work on the
> side, and then any client that tries to read or write to the repository
> finishes up the steps. But the individual file histories refer to the
> global revision history (by index), so you don't have a 'top-down' view
> that makes it all atomic by changing the top level object to point to
> the new lower level objects.

The reason that shouldn't happen is the ordering. If we strip the
changelog first (what you call the global revision history), other
clients won't be able to "find" the any file-level revisions only
referenced by the revision just stripped, so it should be atomic.

Cheers,

Dirkjan