[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Aventures with the dump file format

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2003-12-07 16:38:12 CET

Edmund Horner <edmund@chrysophylax.cjb.net> writes:

> The first test for the filter was to give the same output,
> byte-for-byte, as the input. That was acheived, except for one
> problem: r1 of the test input (generated by svnadmin) had a
> Prop-length that was 5 bytes smaller than its Content-length! (There
> was in fact Content-length bytes worth of props, incl. "PROPS-END\n".)
> Now, as I understand it, revision records don't have any text content.
> Strangly enough, svnadmin had no trouble loading this file. I assume
> it ignored Prop-length and used Content-length instead?

Are you opening the dumpfile input stream without the "binary" flag on
a Windows system? This sounds like a line-ending issue.

> The purpose for my filter is to retroactively add "svn:eol-style:
> native" to file paths matching *.c, etc. From looking at
> libsvn_repos/dump.c, I take it properties are only dumped if the file
> is new, or if they are changed. And in load.c I learned that whenever
> node properties are read from a dumpfile, existing properties for the
> node are cleared first.

That's correct. The dumpfile format does not contain "deltas" between
revisions. If contents are given, you get 'em all.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 8 16:40:26 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.