https://issues.apache.org/jira/browse/SVN-4767

Running tests with the '--dump-load-cross-check' option revealed a minor 
discrepancy between the dump files produced by 'svnadmin dump' and 'svnrdump 
dump' in some test cases.

[...]
 K
 svn:date
 V
- 2015-01-01T00:00:00.000000Z
+ 2015-01-01T00:00:00.0Z
[...]

"svnadmin dump" "canonicalizes" each svn:date revprop while dumping, in the 
function write_revision_record().

This seems to have been done in r842390 in order to upgrade from pre-0.14 
repository format to the new timestamp format introduced in 0.14 -- see issue 
SVN-614 "DAV:creationdate needs to be an ISO8601 date". svn_time_from_cstring() 
reads either new or old format, and then svn_time_to_cstring() writes the new 
format.

However, this does not only convert old to new format, but could also make 
textual changes to the string if the revprop value is not already canonical. 
Dump should carefully output exactly what is in the repository and not 
gratuitously change it. In retrospect, such a transformation should have been 
done during "svnadmin load" instead of in "dump".

While "svnadmin dump" makes this transformation, "svnrdump dump" and 
"svndumpfilter" do not. This could lead to unintended differences in dump 
output depending on which tool is used. (I made some progress in unifying the 
output logic for those three dump producers a couple of years ago, but I left 
this part alone because I did not know what to do with it.)

The discrepancy I noticed above comes from prop_tests.py 41 and 42 which 
explicitly propset svn:date to a value such as '2015-01-01T00:00:00.0Z'. 
"svnadmin dump" was munging this non-canonical value on output, which meant it 
was not a true dump. (Whether a non-canonical format should have been allowed 
into the repository in the first place is a separate issue.)

Therefore I will remove this code path. It even has a comment saying "### 
Remove this when it is no longer needed for sure" which referred to being 
needed for pre-0.14 upgrades. We definitely no longer need that.

-- 
- Julian

Reply via email to