When one uses clones to derive files, Leo is acting as a macro
language from which the derived file is generated. Just as you
wouldn't edit the output of "gcc -E" and expect the change to be
incorporated in one's source code, you can't expect to edit a file
derived from multiple instantiated clones and expect the clones to
reflect those changes. When clones aren't involved, there is a
mapping between the derived file and the leo file, but not otherwise.
The alternatives for collaboration seem to me to be:
A: The Leo file is the source; the derived files the uneditable
objects.
1 (Either) conflicts don't happen because there are only one-at-a-
time edits enforced by locking.
2 (Or) someone invents a directed acyclic graph conflict
resolution tool.
B: The derived files are the source; the Leo file gets derived.
1. Right now, last (for some value of "last") version of a clone
wins (mostly: with cross-file clones, Leo doesn't mark earlier read
files containing the clone as modified, even though it notes when
reading a subsequent clone in an @thin derived file that the node has
changed. Move the @thin file around in the outline, and the woods get
thick. At Leo trunk revno 2705, the second occurrence of a cloned
node within a single @thin file doesn't get written into the derived
@thin file. Is that a feature?).
2. I suggest that variant versions of a clone get uncloned; it
would be useful to generate a warning.
I currently do A1; if I get a sabbatical I'll invent A2 (apparently
the commercial tool oXygen can resolve XML conflicts). Edward's
practice is currently B1. B2 might improve things.
- Stephen
On Jan 20, 2:01 pm, "Edward K. Ream" <[email protected]> wrote:
> On Wed, Jan 20, 2010 at 12:46 PM, thyrsus <[email protected]> wrote:
> > I use cross-file clones. When I do, I consider the Leo file
> > authoritative, and the external files derivative.
>
> @thin is essential in a cooperative environment. We can pull external
> files from the bzr repository without having to update the .leo file.
> We have no choice but to make this work.
>
> > It becomes unwise to edit such derived files outside of Leo because of the
> >likelihood of
> > introducing inconsistencies.
>
> Bzr pulls are such 'edits'. We can't forbid them. We must learn to tame
> them.
>
> Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
