When dealing with some nasty cases in the almost-retired old Google
Code subversion backend, I found a kind of data corruption that the FS
code wasn't catching even though it caught relatively similar issues.
Specifically, find the fold_change function in both of the FS
implementations. There's a check:
/* Sanity check: an add, replacement, or reset must be the first
thing to follow a deletion. */
if ((old_change->change_kind == svn_fs_path_change_delete)
&& (! ((change->kind == svn_fs_path_change_replace)
|| (change->kind == svn_fs_path_change_reset)
|| (change->kind == svn_fs_path_change_add))))
return svn_error_create
(SVN_ERR_FS_CORRUPT, NULL,
_("Invalid change ordering: non-add change on deleted path"));
It might also be nice to check the opposite condition: if change->kind
is add or replace, and old_change is not delete (or reset, I guess),
throw an error. (We had accidentally recorded the sequence "add,
prop-mod, text-mod" out of order as "prop-mod, add, text-mod", which
was interpreted as an "R" below instead of an "A"; this suggested
check would have caught it earlier.)
(Sorry, but I haven't managed to get a proper Subversion build
environment working in a while or I'd send a real patch.)
--dave
--
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
