Hi Daniel,
Daniel Shahaf writes:
> Ramkumar Ramachandra wrote on Wed, Sep 22, 2010 at 22:24:10 +0530:
> > Ok, I think you've misunderstood this. Both of them DO dump the exact
> > same properties. Think of the Prop-delta header as just an extra
> > cosmetic line. In dumpfile v3, everything is a delta against the
> > previous revision including props.
>
> Did you mean: s/In dumpfile v3/In 'svnadmin dump --deltas'/ ?
>
> IOW, the dumpfile format version doesn't enforce that, but svnadmin
> never produces non-delta'd props when it dumps as v3 --- right?
Right. Technically, I meant dumpfile v3 with all the v3 features
exercised :)
> (I think/assume that you can take any v2 dumpfile and just change the
> header from "format: 2" to "format: 3" --- without making any other
> changes --- and still have the result a valid dumpfile...)
That's right. A dumpfile v3 just adds some extra features to v2.
> > When the Prop-delta header is
> > absent, it doesn't mean that the full props are being listed- it just
> > means that the file or directory didn't exist in a previous
> > revision. For a file or directory that didn't exist in a previous
> > revision-
> >
> > * [Prop-delta missing] is a cosmetic way of saying: "Here's a new file
> > or directory along with it's properties."
> > * Prop-delta: true is a cosmetic way of saying: "Here's a file or
> > directory. If it's new, the delta is against nothing. If it's old,
> > the delta is against a previous version. Check it for yourself-
> > information about whether the file or directory is new is already
> > present in the dumpfile."
> >
>
> 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.
-- Ram
Received on 2010-09-22 21:34:07 CEST