On Fri, 2008-11-21 at 12:22 -0500, Greg Stein wrote:
> (sorry for terse response... iphone)
>
> Couldn't you serialize the structure into a skel and store that string
> into the entries file?
I've hardly ever looked at code using skels, so can't answer without
investigating and trying it.
- Julian
> 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
>
---------------------------------------------------------------------
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:43:57 CET