[Top][All Lists]

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

Re: [Monotone-devel] Tailor

From: rghetta
Subject: Re: [Monotone-devel] Tailor
Date: Wed, 11 Oct 2006 22:11:28 +0200
User-agent: Thunderbird (X11/20060915)

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.
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
AFAIK, it should always work this way (i.e. tailor executes deletions before additions).


reply via email to

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