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
