Greg Stein wrote:
> Julian Foad wrote:
> > This raises a question in my head. In editor v1, each child node is
> > referred to simply by its basename, implicitly relative to "the current
> > parent" in the call nesting sequence. When you make a copy of a parent
> > directory, and then start issuing edit instructions within the copied
> > subtree, that all makes sense. If in editor v2 every node will be
> > referred to by its full path (relative to an agreed root), we need to be
> > very careful to define whether the path is the source path or the
> > destination path when the operation might be referring to a node inside
> > a copied/moved subtree. It might sound trivial but do you see what I
> > mean? It's easiest to think about when considering a "move".
>
> The path is *always* relative to the root. Thus, the root must
> encompass all copy/move sources and destinations.
Yup, I got that.
The thing I was concerned about was whether the editor instructions were
meant to be able to be processed out of order or in parallel. The answer
is basically no. At least the /interpretation/ must be sequential, in
the sense that each path refers to the tree structure left by the
previous instruction (not, for example, the tree structure that existed
at the beginning of the edit), and changes to the same node must be
interpreted in the order in which they were given. Therefore,
move A to B
move B to C
moves A to C, rather than moving B to C and A to B at the same time.
There is quite possibly no other sane definition of the ordering of
instructions, but that's what I was wondering about.
On forbidding the driver to issue changes to a node and then delete
it... I agree that there is no good reason to forbid this. In fact, I
can think of an argument for allowing it: I think it would be good if
any two successive editor drives can be combined into a single one
without changing their validity or meaning. So,
- open_root()
- blah1...
- close_edit()
- open_root()
- blah2...
- close_edit()
is defined to be the same as
- open_root()
- blah1...
- blah2...
- close_edit()
If it were not so, a driver that wanted to do such a sequence could just
accept the cost of having to close the edit and re-open it between each
step, but it would be silly if we enforced that for no good reason.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2395200
Received on 2009-09-15 20:29:28 CEST