On Fri, Nov 21, 2008 at 10:37:54AM +0000, Julian Foad wrote:
> I agree it would be better to use an existing format that this custom
> one. But why talk of these other formats when the "entries" file already
> has a format.
>
> Surely we should just use the existing "entries" file format, instead of
> squeezing these fields into a single field of it.
The existing entries file format does not handle a variable number
of items of the same kind. How are you going to fit an arbitrary
number of lines per victim in there? We don't know how many tree
conflict victims there are in advance.
From libsvn_wc/README:
The following fields are allowed; they are present in the order in
^^^^^^^^^^^^^^^^^^^^^^^^
which they are described. Except for boolean fields, the field names
^^^^^^^^^^^^^^^^^^^^^^^^
are not present in the file.
name:
kind:
revision:
url:
repos:
schedule:
text-time:
checksum:
committed-date:
committed-rev:
last-author:
has-props:
has-prop-mods:
cachable-props:
present-props:
conflict-old, conflict-new and conflict-wrk:
prop-reject-file:
copied:
copyfrom-url:
copyfrom-rev:
deleted:
absent:
incomplete:
uuid:
lock-token:
lock-owner:
lock-comment:
lock-creation-date:
changelist:
keep-local:
working-size:
depth:
tree-conflicts:
file-external:
We're simply not using the entries file format as intended, but there
was no better place to store the tree conflict information either.
Now, if we had entries for missing files today, we could store per-victim
information in the victim's entries file and get rid of the tree-conflict
field parser. But I don't see this happening before 1.6, too late.
I think we can support the current format for 1.6 as is. It's hidden
behind an API (read_tree_conflicts_from_entry), has been unit-tested
to the bone (see tests/libsvn_wc, a directory which we added for
the tree conflict info parser), and can be changed in 1.7.
I presume 1.7 will have a much neater way of storing this info anyway,
right Greg? :)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-21 13:23:56 CET