[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1716548 - /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Thu, 10 Dec 2015 15:23:12 +0000

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:23:24 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.