You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2003/12/07 15:38:12 UTC
Re: Aventures with the dump file format
Edmund Horner <ed...@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
Re: Aventures with the dump file format
Posted by Edmund Horner <ed...@chrysophylax.cjb.net>.
C. Michael Pilato wrote:
> Well, just keep in mind that the dumpfile format, while generally
> human-readable, is a binary one. This mean, for example, that if you
> use fopen() to parse it, you must pass the "b" flag to set the input
> style to binary.
Yup, so I'll have to look into making sure stdin is in binary mode.
>>If a loaded dump file node contains props that are exactly the same as
>>the existing props for that path, will the DB record that as a prop
>>change?
>
> Yes. You will be tainting the history of your repository.
Well, that will be a challenge for my filter. But not insurmountable.
Thanks for the info.
Edmund.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Aventures with the dump file format
Posted by "C. Michael Pilato" <cm...@collab.net>.
Edmund Horner <ed...@chrysophylax.cjb.net> writes:
> C. Michael Pilato wrote:
> > Are you opening the dumpfile input stream without the "binary" flag on
> > a Windows system? This sounds like a line-ending issue.
>
> I'm not sure that it is. Running under Cygwin, I haven't had any EOL
> problems that I know about. Though I do get lots of them when
> compiling with -mno-cygwin. I think it's just me messing up my own
> dump file.
Well, just keep in mind that the dumpfile format, while generally
human-readable, is a binary one. This mean, for example, that if you
use fopen() to parse it, you must pass the "b" flag to set the input
style to binary.
> If a loaded dump file node contains props that are exactly the same as
> the existing props for that path, will the DB record that as a prop
> change?
Yes. You will be tainting the history of your repository.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Aventures with the dump file format
Posted by Edmund Horner <ed...@chrysophylax.cjb.net>.
C. Michael Pilato wrote:
> Are you opening the dumpfile input stream without the "binary" flag on
> a Windows system? This sounds like a line-ending issue.
I'm not sure that it is. Running under Cygwin, I haven't had any EOL
problems that I know about. Though I do get lots of them when compiling
with -mno-cygwin. I think it's just me messing up my own dump file.
>>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.
Ok, I have another question.
If a loaded dump file node contains props that are exactly the same as
the existing props for that path, will the DB record that as a prop change?
E.g. if I cause the dump file to contain full props for every node
record, does that have a different meaning from the more usual ommission
of unchanged props?
Or if a loaded node has text that is exactly the same as existing text
for that path, will that be recorded as a text change?
Edmund.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org