Re: [Monotone-devel] Tailor

[rghetta]

Nathaniel Smith wrote:
> On Wed, Oct 11, 2006 at 01:03:01PM +0200, rghetta wrote:
> > Tailor always executes renames before additions.
> > IHMO the source repository is corrupt or the backend outputs impossibile 
> > operations (renaming statistics to statistics/squid makes no sense).
> > Note that all renames involving statistics fail, suggesting a problem 
> > with this directory.
>
> Always executing renames before additions is simply broken.
> http://mebentley.blogspot.com/2005/12/tree-transforms-on-posix-filesystems.html
> is a good summary of the correct algorithm for applying arbitrary
> changes to trees (this was written about bzr, but they happened to
> re-invent the same algorithm mtn uses, suggesting that it is indeed
> the right way :-)).
Perhaps this is one of Tailor limitations. Unfortunately Tailor knows 
nothing about the internals of the scm involved.
AFAIK, a changeset replay in Tailor is more or less done this way:
 - the source backend asks the source scm to update the working copy. 
After this step the wc is like a tree snapshot after the changeset. 
Tailor however doesn't know which steps the source scm/backend took to 
update its wc.
 - the source backend returns to Tailor a list with an high level and 
limited view of the changes made in the current changeset. This mapping 
isn't much sophisticated and can be lossy (for example, file attribute 
changes are ignored).
 - the changes list is passed to the target backend and transformed 
sequentially in target scm commands. Since the wc is already in its 
final state, most of these commands update only the scm repository.
Since Tailor (and the target scm) see only the final wc, you really 
can't split the renames in two, or execute file content changes between 
deletions and creations. At least, not without drastic changes in Tailor 
itself.
Tailor limitations aside, Brian's log reports a rename from statistics 
to statistics/squid which imho just doesn't make sense (and monotone 
obviously complaints).

> > Directory addition in Tailor adds only the directory itself, without 
> > files.  Directory addition in Monotone is recursive, and adds also 
> > contained files and directories. Due to Tailor internals, this 
> > difference can interfere with renames, so the monotone backend strips 
> > away directory additions (note that adding a/b adds automagically the 
> > directory a).
>
> This might have worked better before 0.26, when mtn started tracking
> directories... passing --depth to add might let you work around it.
Add allows --depth ?  My copy of monotone (0.30) outputs "mtn: misuse: 
unknown option depth"

> OTOH, it might not be the problem at all, since add foo/bar should
> implicitly add foo/ if it hasn't been added before -- _if_ you have
> correctly told monotone to forget about some pre-existing file named
> foo/.
AFAIK, it should always work this way (i.e. tailor executes deletions 
before additions).

Riccardo