Thanks for the explanation. Given that svnrdump's output, as is, is semantically correct, and the only issue here is consistency with svnadmin (which produces a different output with the same semantics), and that it's more than a trivial bit of work to get the consistency, +1 for leaving svnrdump as is.
Daniel Ramkumar Ramachandra wrote on Thu, Sep 23, 2010 at 01:02:01 +0530: > Daniel Shahaf writes: > > In other words, the only case where svnrdump and svnadmin disagree on > > the presence of the "Prop-delta:" header is in the case of > > added-without-history files; and in that case, svnrdump prints it and > > svnadmin doesn't, and this doesn't matter since interpreting the dumped > > hash as a delta or as an absolute full properties list gives the same > > result... > > > > Right? > > Exactly! > > > P.S. Doesn't the "Node-action:" header allow you to distinguish whether > > it's a newly-added file or not, and thus be able to generate Prop-delta: > > only in the cases that svnadmin generates it? > > Yes. Unfortunately, the actual dumping is separated from determining > *what* to dump which is why dump_editor needs ugly hacks like > dump_props and dump_newlines. > > To solve this problem, we have to reverse-engineer what `svnadmin > dump` dumps. It should then be possible to determine what happens in > the edge cases: is_copy replace, is_copy add, is_copy change etc. Then > we have to set another flag, extend dump_props to accept another > argument and conditionally write that Prop-delta header. To put it > tersely, it's non-trivial, inelegant and time consuming- plus, it's > not priority, considering that many other headers mismatch anyway.
