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