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

Re: svn commit: r34293 - branches/tc_url_rev/subversion/libsvn_wc

From: Neels J. Hofmeyr <neels_at_elego.de>
Date: Fri, 21 Nov 2008 06:33:21 +0100

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


Received on 2008-11-21 06:33:55 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.