Le lun 15/07/2002 à 16:38, cmpilato@collab.net a écrit :
> =?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.
Sorry.
>
> > > 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.
A new behavior (don't dump always both) that i missed.
> The problem is that the following operations really are important for
> us distinguish between:
>
> svn copy foo bar; svn ci
>
'Node-path: bar
'Node-kind: file
'Node-action: add
'Node-copyfrom-rev: 4
'Node-copyfrom-path: /foo
'
'# no change. Go to next node or revision ...
'Node-path
> svn copy foo bar; [edit bar's text]; svn ci
'Node-path: bar
'Node-kind: file
'Node-action: add
'Node-copyfrom-rev: 4
'Node-copyfrom-path: /foo
'Content-length-text: ??
'...\n
'# if change in props
'Content-length-props: ??
'...\n
we have a clean distintion between text/props and new content or no.
For compatibility, the new loader need too always understand the old
"Content-length".
It's a proposition only.
>
> 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.
Sure.
Now i try to be less "verbose". I think i don't have the background
needed to move forward.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 16 05:20:47 2002