monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Tailor


From: Nathaniel Smith
Subject: Re: [Monotone-devel] Tailor
Date: Wed, 11 Oct 2006 14:30:09 -0700
User-agent: Mutt/1.5.13 (2006-08-11)

On Wed, Oct 11, 2006 at 10:11:28PM +0200, rghetta wrote:
> 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.

The algorithm involved here has more to do with the basic semantics of
adds/deletes/renames than any particular scm internals.

> 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).

A rename like that makes perfect sense... the question is how to
convince tailor to present it sensibly.

> >>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"

Err... maybe not.  Sigh.

> >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).

But foo/ might have disappeared because it was renamed, rather than
because it was deleted :-).

-- Nathaniel

-- 
The best book on programming is still Strunk and White.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]