[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: Bert Huijben <b.huijben_at_competence.biz>
Date: Fri, 21 Nov 2008 13:26:45 +0100

> -----Original Message-----
> From: Greg Stein [mailto:gstein_at_gmail.com]
> Sent: vrijdag 21 november 2008 5:01
> To: dev_at_subversion.tigris.org; julianfoad_at_tigris.org
> Subject: Re: svn commit: r34293 -
> branches/tc_url_rev/subversion/libsvn_wc
>
> 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.
>
> I'm not sure when this snuck into the code, but I'm a big -1 on another
> format.

The format used internally in libsvn_wc will only be used in Subversion
1.6.X as conflict data doesn't have to be stored in entry files when we have
the sqlite store.

>
> Use skels or svn structures. But not a new format.

If I look at those, using skels and the svn protocol both require making
library local data serializers usable by other libraries, while those two
formats weren't designed to be used in our entry files. (And the entry file
format itself doesn't allow multiple fields of the same type on a single
entry).

I don't see why adding the temporary (very simple) serializer (that can be
moved as read only to the wc upgrade code after 1.7 introduces the new wc
store) would harm us here.

I would guess that opening up the skels or serializer for reuse outside
their libraries will give more maintenance in future releases, than just
using the code as is.

        Bert

---------------------------------------------------------------------
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:26:59 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.