> -----Original Message-----
> From: Hyrum K. Wright [mailto:hyrum_at_hyrumwright.org]
> Sent: vrijdag 25 september 2009 15:12
> To: Greg Stein
> Cc: Bert Huijben; dev_at_subversion.tigris.org
> Subject: Re: svn commit: r39580 - trunk/subversion/libsvn_wc
>
>
> On Sep 24, 2009, at 9:11 PM, Greg Stein wrote:
>
> > On Thu, Sep 24, 2009 at 20:21, Hyrum K. Wright
> > <hyrum_at_hyrumwright.org> wrote:
> >> On Sep 24, 2009, at 5:04 PM, Bert Huijben wrote:
> >>
> >>> Author: rhuijben
> >>> Date: Thu Sep 24 14:04:20 2009
> >>> New Revision: 39580
> >>>
> >>> Log:
> >>> Update the WC metadata schema to reflect the new idea about storing
> >>> conflicts. We will store all conflicts in a TEXT field of the
> >>> ACTUAL_NODE
> >>> table serialialized via the skel api.
> >>
> >> Forgive me for being dense, but why are we using skels here? Why
> >> should we worry about serialization when a structured format (which
> >> is
> >> what SQL is meant to be) does that for us?
> >
> > Same reason we serialize properties: we probably don't need the
> pieces
> > of data available for manipulation/query individually, and a skel can
> > be easier to deal with when 1:N mappings exist (one node, N prop
> > conflicts) and we want *all* N all the time.
> >
> > We *could* have a prop_conflict_data for that last 1:N element, but
> we
> > still don't really need separable access to the other data items.
> (or,
> > at least that's my impression)
>
> Ah, yes, this thought occurred to me after I sent the above mail. We
> do have a public API which returns three booleans, set depending upon
> whether or not there is a prop, text, or tree conflict. Implementing
> this API becomes less straightforward when we have to fetch all the
> conflicts all the time (as opposed to "select count(*) from
> conflict_victim where kind = 'foo' and wc_id = ... and local_relpath
> = ..."), but it remains to be seen how this API is used and whether or
> not its callers need updating.
>
> Or the code could have churned so much in the last week that the above
> concern is a non-issue. :)
All these values of this function are false if there is no conflict skel in
the actual table for the specific node. (Which is the typical case for 99%
of all files in your working copy).
In many cases we can just check "is there some conflict?" instead of the old
3-way check that had to check all types to get the 'any' answer.
Bert
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2400228
Received on 2009-09-25 15:32:30 CEST