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

Re: problem with dump/load

From: <cmpilato_at_collab.net>
Date: 2002-07-15 16:38:58 CEST

=?ISO-8859-1?Q?F=E9liciano?= Matias <feliciano.matias@free.fr> writes:

> > It is not THE solution, and it is not even accurate, unfortunately.
>
> But it solve my problems of dump/load (for my current repository and the
> exemples give in that thread).
> I think this patch is right (perhaps incomplete) but it hide over
> problems.
>
> it's right because "notes/fs_dumprestore.txt" :
> ' The content section has two implicit parts: a property hash, and the
> ' fulltext. The division between these two sections is implied by the
> ' "PROPS-END\n" tag at the end of the prophash. In the case of a
> ' directory node or a revision, only the prophash is present.
>
> A node, if it's a file, can not have only a prophash section or only a
> fulltext section.

That is correct. It must have both sections. However, that doesn't
mean *either* is populated with real contents. It just means that the
contents section is laid out like:

   prop-stuff"\nPROPS-END\n"text-stuff

where prop-stuff or text-stuff, both, or neither, could be the empty
string.

Part of the problem is that the fs_dumprestore.txt file doesn't
explain some of the quirks of the dump file format -- it really exists
just to describe what a valid file might look like, not how to
interpret that file.

> > The dumper was designed so that if the "text" of a copied file did not
> > change, that text was not dumped.
>
> Property and content must always be dump.

Why are you arguing with me? I helped to design the dump file format,
so I think I know a little bit about it.

> > First, it doesn't *need* to be
> > dumped because the loader gets it for free when *it* does the copy
> > again at load time.
>
> No since "Node-action" is set to "change".
>
> > Secondly, it leaves us unable to easily ask of
> > the new loaded repository, "Did the text of this file change?" because
> > all such files will look (initially) as though they have textual mods.
> >
>
> The dump format can not store diffs of file. It say, file change
> (proprety or text") and this is the new content (proprety and text").

I think you're missing something crucial. While the dumper, as you
know, doesn't give content diffs (like Unified Diff or svndiff or
...), it *does* give tree diffs. That it, every revision is described
as a diff against the previous revision. That's why only the changed
nodes show up in each revision, not the entire tree.

When the dumper and loader where first written, they did exactly as
your patch did -- if either props or text changed, both were dumped.
The problem is that the following operations really are important for
us distinguish between:

    svn copy foo bar; svn ci

    svn copy foo bar; [edit bar's text]; svn ci

With both text and props always being dumped, we cannot tell the one
from the other. Also, it keeps our file format smaller if we don't
have to repeat unchanged text.

Hm. *thud*. I've timed out on this mail for the moment. Hope I've
cleared *something* up.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 16 04:41:09 2002

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.