On Tue, Jan 07, 2003 at 04:46:58PM -0600, Ben Collins-Sussman wrote:
>
> I can't remember... did someone have a good technical argument for
> storting the GUID as a revprop?
>
<mbk> how do you feel about the relative costs of using rev-0 props vs. widening the ra interface?
<ghudson> I like the rev 0 prop idea.
<mbk> I think each of us is worried about a different slippery slope. :-)
"let's just add another ra function" vs "let's just add another property"
I worry that the propget/propset codepath will become more and more
complex as we add more and more distinguished properties.
this one would need to be read-only. what about the next one?
<ghudson> Perhaps you're right.
<mbk> Perhaps you're right. :-
I'm adding the property right now; we can always change it later. :-)
<rassilon> blech. rev-0 properties. blech. such a hacky approach
<mbk> but easily extensible.
<rassilon> Not in a clean way, it has all sorts of issues.
<mbk> so does protocol versioning.
<rassilon> If you want an extensible configuration namespace
just add a configuration root TxnID
* mbk argues 3 sides of the same coin.
<pilchie> are you guys still arguing about repository guids?
<mbk> not arguing. discussing. :-)
<ghudson> Still there? I have an interesting thought experiment along these
lines. Suppose inode fields in Unix had been implemented using
properties (a string to string mapping).
* mbk supposes.
<ghudson> On the upside, when it comes time to add new information,
you don't have to add or amend system calls, C library bindings,
perl and python bindings, or even command-line programs; you
have a nice end-to-end pipe between the kernel filesystem code
and the user (or tools closest to the user, as appropriate).
On the down side, the kernel fs code would have to have complex
controls on the properties. "size" has to be automatically
set, and has to either be read-only or changing it has to
truncate or expand the file. "ctime" has to be controlled
so that max(ctime,mtime) is always the last alteration time
of the file. And so on. Unfortunately, this wasn't a very
conclusive thought experiment. :)
<mbk> I think it's a good analogy, though.
I think the results depend on the cost of changing the API.
If it's acceptable to add another syscall every now and then, you get
one result
if it isn't, you get the other.
<ghudson> I'm also concerned with architectural consistency. We use
properties for commit information, for instance, and we do
that by complicating the props code path. If we decide that
repository guids shouldn't be implemented as properties,
maybe the same decision should apply to commit information.
<mbk> then what are the revprops for, again? :-)
a crutch for incomplete design?
<ghudson> Users might still have a use for them. (Although, more of a
use if you could atomically commit a rev with rev-props.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 8 01:39:11 2003