On Wed, 04 Jun 2008 08:36:19 +0200
Walter Franzini <[EMAIL PROTECTED]> wrote:

> Is there some documentation of the rules that a *tailor* Changeset
> must follow?

The idea behind tailor CS is that they represent a "neutral" view wrt
concrete changesets of a particular VC. With that I mean, for example,
that even when the particular VC does not support say "directories"
like CVS or HG, when tailor builds the changeset from these systems it
introduces fake ADD_DIR/REMOVE_DIR entries as appropriate; as another
example, SVN does not have an atomic RENAME but it rather use a
ADD(COPY)+DEL: tailor recognizes that and collapses the two in one
RENAME.

The goal of course is to smooth as much as possible the path thru the
target backend.

I plan to change them quite a lot in tailor v2... but in the
meanwhile I'll try to answer and clarify any doubt :-)

> 
> Having a good knowledge of the aegis changeset model but zero of other
> systems I need some clarification.
> 
> The following holds for aegis:
> 
> * file operations: create, modify, remove, rename, insulate,
> transparent
> 
>   create, modify, remove and rename has a natural mapping in the
>   tailor changeset model.
> 
>   I don't see a mapping for insulate and transparent.  Insulate is not
>   a problem since it's a valid operation only for uncommitted
>   changeset, while I don't know if other system has an operation
>   similar to transparent (see aemt(1)).

There's no aemt(1) on my system, can you describe the transparent
concept a little?

> * for each changeset only 1 operation is allowed on a file.
> 
>   Since I've seen some system (i.e. darcs) permits more than one
>   action per file on a single changeset, this rule means that the
>   aegis target backend must collapse operation sequences.
> 
>   Under aegis, renaming a file and modifying its content result in a
>   single operation: rename.  Should the (not yet written) source
>   backend split it in a REN followed by an UPD?

Well, it depends on what you mean. Usually UPD events have a very low
significance, because the target is of course able to auto-determine
that: most target backends simply ignore the UPD entries; I do not
think that anything will break if aegis produces just a REN in place
of REN+UPD.

> 
> How a target backend should use the old_revision, new_revision and
> status member of a ChangesetEntry?

Just ignore those, they are used by the CVS backends, and should
really moved down to a CvsChangesetEntry or equivalent. The CVS
machinery was the very first piece of code...

> Expects more questions :-)

Welcome!

ciao, lele.
-- 
nickname: Lele Gaifax    | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas    | comincerò ad aver paura di chi mi copia.
[EMAIL PROTECTED] |                 -- Fortunato Depero, 1929.
_______________________________________________
Tailor mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/tailor

Reply via email to