[Python-Dev] Workflow proposal

John Arbash Meinel john at arbash-meinel.com
Wed Mar 23 12:39:41 CET 2011

Hash: SHA1

On 3/23/2011 4:30 AM, Stephen J. Turnbull wrote:
> Antoine Pitrou writes:
>  > Now, "hg strip" should definitely be absent of any recommended or even
>  > suggested workflow. It's a power user tool for the experimented
>  > developer/admin. Not the average hg command.
> So what you're saying is that Mercurial by itself can't support the
> recommended workflow, because any "collapsing" of commits requires
> stripping, whether done by hg strip or implicitly by some other
> "non-average" hg command.

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

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.

It is possible that they only rewrite the revisions file, leaving blanks
for the old references. But the statement "it rewrites the numbers"
means it is collapsing the offsets in the index.

I definitely would be very leery of putting that in any sort of
recommended documentation. It also makes me understand more why hg folks
value having "hg check" run very quickly...

Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the Python-Dev mailing list