On Tue, 2009-09-01 at 22:58 +0200, Neels Janosch Hofmeyr wrote:
> Hi Greg and All,
>
> am busy with editor v2's API docs, and got another few considerations/questions.
>
>
> () The new callbacks use a REL_PATH argument consistently. But the editor
> interface really makes no restriction on the path whatsoever (yet). It seems
> that it serves no purpose to call this REL_PATH instead of just PATH. But:
>
> The usual case will be that producer and consumer agree on a base path, and
> the paths passed to the callbacks are indeed relative. In that case, it
> serves the consumer code readability to call it REL_PATH.
>
> Furthermore, if we are to add a debug/validation layer that enforces the
> constraints outlined by the API description, we might want to have some
> checks against the paths passed, e.g. whether all children of an added
> directory are indeed added later. In that case, it would also be good to
> enforce a very specific path format, as in "this/is/a/path". Agreed?
> (What's that called, "Subversion's internal path format"?)
Thinking about how the editor is supposed to communicate changes to "a
tree" (examples: a versioned tree in the same repo, or an unversioned
tree on disk or represented in a patch file), I would say yes, require
paths to be in the Subversion-internal format (separator always '/'),
not starting with '/', and relative to an externally-agreed root.
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".
move A/B to A/C
edit A/C/file1 # looks logical
edit Z/C/file1
move Z/B to Z/C # is this sequence meaningful? allowed?
Is there an ordering restriction, perhaps that operations on a parent
must come before operations on any children?
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2394655
Received on 2009-09-14 16:56:28 CEST