subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <julianf...@gmail.com>
Subject Re: svn commit: r1716548 - /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c
Date Thu, 10 Dec 2015 14:27:44 GMT
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

Mime
View raw message