Karl Fogel <kfogel@newton.ch.collab.net> writes:
> Ben Collins-Sussman <sussman@collab.net> writes:
> > > 2. (much more involved solution) Promote all entry members to
> > > first-class citizens, and in doing so, might I recommend losing
> > > the "attributes" hash that lives in the entry, too? That hash is
> > > a transient state between disk and structure, and need not be
> > > toted around everywhere we go. The day someone actually has
> > > custom entry things to track, a hash for ONLY those custom items
> > > can be re-added.
> >
> > Karl and I have been talking about doing this for a while now. It's
> > the Right Thing.
>
> Yah, iirc we discussed this with Greg Stein when he was in town the
> other week, too. I think doing the Right Thing is worth it here, even
> though it takes a little more time. Let's get the svn_wc_entry_t mess
> cleaned up once and for all.
Anybody volunteering here? I can work around the problem in my new
code until the svn_wc_entry_t work is finished, or I can fork off and
do the entry work.
> Question, folks: do we want an open structure with settable members,
> and a pair of reader/writer conversion functions? Or do we want an
> opaque structure with accessor methods?
Open, sheesh. The only reason I can imagine having accessors is so we
can perform validation of "set" requests, and I think that so long as
the working copy library does NOT expose it's entry *writing*
functionality (that is, folks outside the WC library have read-only
access to the entry structures), we don't need that overhead.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 14 16:52:19 2002