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 13:19:14 CET