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

Re: svn commit: rev 1508 - trunk/subversion/include trunk/subversion/libsvn_wc trunk/subversion/bindings/ruby

From: <cmpilato_at_collab.net>
Date: 2002-03-14 16:49:56 CET

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

This is an archived mail posted to the Subversion Dev mailing list.