(Just changing the subject line.)
On 10 December 2015 at 15:23, Philip Martin <philip.martin_at_wandisco.com> wrote:
> Julian Foad <julianfoad_at_gmail.com> writes:
>
>> Stepping back a little, I want to pose the rhetorical question: Who is
>> to say which FS layer implementation is the wrong one? BDB is the
>> earlier implementation. If we define correctness by precedent, then
>> it's the FSFS behaviour that we should consider to be wrong. On the
>> other hand, if we define correctness by specification, then we need to
>> specify this behaviour somewhere, not just "randomly" change it.
>
> We could leave it unspecified, or explicitly specify that the backend
> has a choice.
>
>> So let's try to enumerate the issues.
>>
>> (1) In FS-BDB, a no-op commit may or may not produce a new root
>> node-rev (depending on the specific form of the commit), whereas in
>> FSFS, every commit produces a new root node-rev.
>>
>> (2) FS-BDB reports a different result from svn_fs_txn_base_revision()
>> before and after reloading by name, when the no-new-node-rev situation
>> in (1) occurs.
>>
>> (3) A recently added check can reject valid delete operations when (1)
>> and (2) occur.
>
> I'd say the check relies on (2). The check is not explicitly assuming
> anything about the root nodes. It is a backend bug that BDB uses the
> root node as a proxy for the base revision and causes the bug.
>
>> Which of those are bugs, which are acceptable, which need to stay as
>> they for backward compatibility even if they are bugs, and so on?
>>
>> It seems to me that (2) is definitely a bug, but I'm not sure about
>> (1) and therefore not sure about (3).
>
> (2) is a bug. We fix it by making BDB always make a new root node.
>
>> Daniel Shahaf wrote on 27 Nov:
>>> Can the problem happen on nodes other than the root? I haven't tried
>>> it, but I wonder if a open_root/open_directory/close_directory/close_edit
>>> editor drive might lead to an instance of this problem on the directory
>>> that was opened and closed without modification.
>>
>> Yes, that's an important question too. In other words, what semantics
>> do we want for a "no-op change" in general, within a commit?
>>
>> And is it possible to make a commit which starts with opening (as the
>> root of the commit) a directory that is not the root of the
>> repository, and if so, what about that case?
>
> I don't think that is relevant. This about the FS API so the calls are
> begin_txn and commit_txn.
>
> --
> Philip Martin
> WANdisco
Received on 2015-12-10 16:43:25 CET