Re: more editor v2

Julian Foad wrote:
> 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?

There are a number of ordering restrictions, but it's more on the order in
which an individual path must be manipulated. We should forbid the second
case above. Now is the time to formulate the proper API definition.

Imposing "parents first" seems too restrictive to me. For example, it's
perfectly ok to edit a file and change its parent dir's props later.
I feel like writing "The order of API calls must make sense" :P

I'm saying that we could even allow:
  edit Z/B/file1 # edit file in first position
  move Z/B to Z/C

(But with our current code base, this case probably won't happen anyway, as
far as I know at least.)

How's this, does it contain enough restriction? :

"The producer must issue the editor calls in a logical sequence, so that
calls do not manipulate a path before that path is created (using add, copy
or move) nor after such a path was obsoleted (e.g. using delete or move)."

We could also add:

"The editor calls must not manipulate a path _before_ it is replaced or
deleted." (Why produce edits when the path is going to be removed anyway)

But it forbids sequences like this:
  copy A to B
  edit B
  copy B to C
  atomically replace B with A
It's an ambitious sequence, I know, and it is equivalent to
  copy A to C
  edit C
  copy A to B
which I'm wildly guessing is what our current code will always automagically
collapse to anyway.

Still, with an eye ahead towards a possible dawning of operational merges in
a foggy, hypothetical future, it might pay off to just leave it open for
interpretation by driver/receiver implementations.

BTW, thanks for picking this thread up again, Julian :)

~Neels

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2394810