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

Re: WC entry format for tree conflict data

From: Greg Stein <gstein_at_gmail.com>
Date: Fri, 21 Nov 2008 12:22:27 -0500

(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)

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.


On Nov 21, 2008, at 7:18, Julian Foad <julianfoad_at_btopenworld.com>

> 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

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.