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.
Received on 2010-09-22 22:41:49 CEST