(Just changing the subject line.)
On 10 December 2015 at 15:23, Philip Martin <philip.mar...@wandisco.com> wrote: > Julian Foad <julianf...@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
