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

Re: Repository GUIDs again

From: mark benedetto king <mbk_at_earthquake.boredom.org>
Date: 2003-01-08 01:38:26 CET

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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.