Philip Martin wrote: > This discussion seems to have died out. Are we going to leave the BDB > code as is, in which case we should mark the failing test XFAIL, or make > a change? I still prefer the option that makes the root path mutable on > commit, primarily because for the vast majority of commits there is no > change at all.
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. 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. 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). 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? If we don't address these questions as well, we might not be making much progress by addressing (1) and (2) and (3) only. - Julian
