(sorry for terse response... iphone)
Couldn't you serialize the structure into a skel and store that string
into the entries file? You're right that entries is oriented to single
value fields, so a skel serialize can give you the single (string)
value.
For 1.7, we might be storing serialized data into sqlite. It really
depends upon our access pattern. Point is: serialization will still be
important then, so this might not be so temporary.
Cheers,
-g
On Nov 21, 2008, at 7:18, Julian Foad <julianfoad_at_btopenworld.com>
wrote:
> On Fri, 2008-11-21 at 10:37 +0000, Julian Foad wrote:
>> On Fri, 2008-11-21 at 06:33 +0100, Neels J. Hofmeyr wrote:
>>>
>>> Greg Stein wrote:
>>>> On Thu, Nov 20, 2008 at 20:33, Neels J. Hofmeyr <neels_at_elego.de>
>>>> wrote:
>>>>> Greg Stein wrote:
>>>>>> Woah... I just noticed what is going on here.
>>>>>>
>>>>>> Why are we not using skel's or the svn protocol structures? I
>>>>>> seriously disagree with adding Yet Another Storage Format into
>>>>>> our
>>>>>> code. This is ridiculous.
>>>>> Sorry, I was being ignorant about it. The code snuck in with
>>>>> merging-to-trunk of the tree-conflicts branch. Wasn't me :)
>>>>> Do you consider this a 1.6 blocker?
>>>>
>>>> Yup.
>>>
>>> I think we can live with that. Shouldn't be too difficult, it's
>>> after all
>>> just some string parsing hidden away in a subroutine. But it's
>>> another drop
>>> in the barrel for sure. :(
>>>
>>>> We've got too many formats already (ref: entries format, prophash
>>>> format, config format, etc).
>>>
>>> I see your point...
>>>
>>>> \> Could you point me at a function or struct type that you mean
>>>> by saying "the
>>>>> svn protocol structures"?
>>>>
>>>> include/svn_ra_svn.h
>>>
>>> Heh, I saw that, but I hoped to get something more specific ;)
>>>
>>>> There may be some advantages of the svn serialization format over
>>>> skels, but I'm not well-versed enough in the two formats to
>>>> provide a
>>>> compare/contrast. But the two formats are solid and already at the
>>>> core of svn.
>>>
>>> Does someone out there recommend to use svn serialization over
>>> skel? (for
>>> storing a struct in an entry string, which contains paths, URLs,
>>> node_kind_t
>>> and some enums and numbers).
>>
>> 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.
>
> History: when I started on this code, I saw it and thought that.
> But...
>
> * It was handy to have it all in one field so it doesn't break
> people's
> WC when we tinker with it.
>
> * It's a way to get a variable number of fields in one "entry". The
> "entries" format doesn't otherwise support that.
>
> It's a serious concern that it's another parser where it would be
> better
> to re-use something if there's something suitable. But it looks like
> the
> "entries" format is incapable.
>
> We wouldn't need multiple things in one entry if we change to
> storing an
> entry for every victim, and that now looks like the right thing to do.
>
> Re. backward compatibility: It's possible that the compatibility code
> only needs to live in "tools/.../change-svn-wc-format.py", maybe not
> in
> Subversion itself.
>
> It looks to me now like the burden of keeping it for 1.6 and
> changing to
> something better afterwards is not too high. Please say if there is
> anything difficult that I've overlooked.
>
> - Julian
>
>
---------------------------------------------------------------------
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 18:22:50 CET