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.
The existing skel and svn serialization formats have been tested,
debugged, and verified as being future-proof when extensions are
needed. Introducing Another Format means we have to go through all of
that yet again, *and* then continue to maintain it moving forward. And
it means that developers will have to read/parse/debug another format
rather than working with an already-known format.
We've got too many formats already (ref: entries format, prophash
format, config format, etc).
> skel_t looks interesting but it doesn't live anywhere outside
> libsvn_fs_base. It seems to be used a lot in bdb, that's a plus. So I'd make
> the skel API public. Would that be fine, is skel ready for that?
skels have been around since Day One, so they're certainly safe.
\> Could you point me at a function or struct type that you mean by saying "the
> svn protocol structures"?
include/svn_ra_svn.h
Looking through that code, I'm not sure if the format can be used
outside of an svn connection. Others may have more information.
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.
Cheers,
-g
---------------------------------------------------------------------
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 05:47:11 CET