Re: The Four Elements of Righteousness

On Thu, Jul 18, 2002 at 09:50:13AM -0500, cmpilato@collab.net wrote:
>...
> I think *I'm* missing something. Both Greg's and Karl's plans here
> make the ra->set_wc_prop() function seem quite a bit misnamed. That
> is, this operation:
>
> callbacks->set_wc_prop (path, pname, pvalue1);
> pvalue2 = callbacks->get_wc_prop (path, pname);
>
> could totally result in pvalue1 != pvalue2 (the property values, not
> the pointers to them, you picky goons).

Ah. Good point. Hadn't seen that.

We can fix it to retain the intent, or we can alter the specification. For
example, we could hold all changes in memory (suck!), or we could have the
"get" look at Karl's holding file. Something like:

  1) get the prop from .svn/tmp/queued-wcprops/FILENAME
  2) if not avail, get from .svn/wcprops/FILENAME

> This is a *broken* API.

Dude. Chill out. The *suggested* change breaks the API. You've found a hole
in the idea that we need to remedy. That's all.

Personally, I never even thought the set/get through. I was mostly concerned
about the transactional requirement.

> All
> I can recommend is that set_wc_prop() become queue_wc_prop_change(),
> and then we document that the queue isn't played into reality until
> "some unpredictable point in the future".

I've reviewed ra_dav, and it would actually be fine with this. It will never
attempt to read a value *after* it has set a new value. So as far as it is
concerned, the WC can never change it.

> That is NOT the way to write an API.

Woah. Relax.

> I mean, the RA layer can really
> never know when it is safe to try to read back a value it wrote.
> Although I guess we could document around the problem, saying that the
> RA layer can expect its changes to take effect, oh, by the next time
> the RA layer is opened.

We obviously need to put the (changed) properties somewhere other than
.svn/wcprops/, until they're committed, so that definitely means that we can
open the temporary location to read props, thus retaining read-consistency
with the current API.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org