Daniel Shahaf <[email protected]> writes: > Philip Martin wrote on Tue, Nov 26, 2013 at 11:53:05 +0000: >> The result is a revision file that contains duplicate nodes, multiple >> change lists, etc. The problem is likely even worse if changes are >> made to the transaction between the calls to svn_fs_commit_txn. >> > > Assuming there are no changes to the transaction, is there a correctness > problem resulting? Or is the problem simply one of wasted space, i.e., > the resulting revision file would contain N copies of the change list > but only one copy would be pointed to?
I don't know, I expect it depends on implementation details of the FSFS code that reads revision files. I've attached a repository in which I have triggered the problem on this commit: svnadmin create repo svn import repo/format file://`pwd`/repo/f so it contains r1 with one file rep, two nodes 'f', two nodes '/', two change lists and two final offset lines. The two 'f' nodes refer to the single file rep and are the same but the two '/' nodes refer to different 'f' nodes and so are different. "svnadmin verify" and "svnadmin dump" do not report errors. "svnlook tree --show-ids" shows the second set of nodes and ignores the first set.
repo.tar.bz2
Description: Binary data
-- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
