Re: [Monotone-devel] How to apply "automate get_revision" data

[Nathaniel Smith]

On Sun, Nov 11, 2007 at 11:39:55AM -0600, Brian Downing wrote:
> I was wondering if there is a reliable way to apply the data from 
> "automate get_revision" to transform one revision to the next.  I'm 
> toying with a monotone to git converter, which is pretty simple,
> but "automate get_manifest_of" is painfully, painfully slow.  (Around 
> 3/4 second for the OpenEmbedded repository on my machine.)

You might want to try using 'automate stdio'; if you do
get_manifest_of through automate stdio, then the successive
invocations can share caches.  Depending on what order you're fetching
the manifests in, this may turn an O(n) operation into an O(1) one
(where n is history size -- delta reconstruction has to walk the
history graph).

> "automate get_revision" is pretty fast, but consider this example from 
> the monotone repo:
[...]
> I have no idea what order to apply that information to get something 
> sane.  Certainly renaming a file (to itself?) after deleting the 
> directory it lives in makes no sense to me.  Trying a simple 1:1 mapping 
> to git-fast-import seems doomed to fail, as the first "delete win32" 
> blows the whole thing away, including "win32/read_password.c".

In general, there is no order you can apply them in; they are to be
applied "all at once".  It's more like a declarative description of
how two trees map to each other than it is a procedural description
of how to produce one tree from another.  The algorithm for working
with such things is a little subtle; the best description I know of
is:
  
http://mebentley.blogspot.com/2005/12/tree-transforms-on-posix-filesystems.html
(This is Aaron Bentley talking about bzr, but mtn and bzr
independently invented identical algorithms here, so it still
applies.)

-- Nathaniel

-- 
"Of course, the entire effort is to put oneself
 Outside the ordinary range
 Of what are called statistics."
  -- Stephan Spender