Bert Huijben <bert_at_qqmail.nl> writes:
> I'm not sure if we should really allow this.
>
> The delta editor explicitly describes that you are opening a directory and
> then edit the nodes inside. Only changing properties on the root is allowed
> and other operations are all on nodes within. Allowing to open the node
> itself again may cause all kinds of problems as there are now multiple
> handles pointing to the same thing. How will this be expressed in the
> filesystem/transaction?
>
> I'm surprised that all the other filesystems allow this, so perhaps this
> is a safe change... but the documentation in svn_delta.h doesn't describe
> this as a safe extension. (Which would theoretically allow this as a safe
> extension in later versions... but we must make sure that we are not
> opening new issues this way)
>
> Currently I would guess that making the ra layers provide a proper error
> for this case would not be a bad thing... All our drivers explicitly open
> an existing directory when they want to edit a file...
I think that I have missed that open_root() must open a directory and so
it cannot be used when working with a file URL. This, in turn, means
that the test example is indeed an undocumented/invalid usage of the
delta editor API and that it works by a coincidence.
I can propose doing the following:
(1) Keep the new simpler check in maybe_set_lock_token_header() — as,
unless I missing something, there should be no reason to explicitly
filter empty relpaths for the lock tokens since they are invalid.
(2) I am going to tweak the new test so that it would properly open the
parent directory and commit to a locked file, to have this case
covered with a native test.
Thanks,
Evgeny Kotkov
Received on 2017-11-21 21:11:46 CET