>Then I thought: well, what if we had unversioned properties on files?
>Ah, but then they wouldn't work well with the normal 'update'
>mechanism. We still need the properties to be versioned, we just
>don't want them to propagate to future revisions automatically.
>
>So naturally, my third thought was: what about "ephemeral properties"
>that are automically removed on the next commit? That would get you
>the desired behavior, for both files and dirs.
>
>My fourth and fifth thoughts were, respectively:
>
>Ick, do we really want to implement that in Subversion?
>
>But wait, it would be easy to layer this as process on _top_ of
>Subversion. You can do it by choosing some conventions for the name
>and values of these properties, then have a pre-commit hook that
>checks to make sure the property is never carried forward. (You could
>also add some client-side logic in the form of wrapper scripts, to
>avoid the annoying rejection-from-server cycle in the first place --
>the pre-commit check would just be extra insurance.)
>
>I agree this is not as nice as having the support directly in
>Subversion, and I'd like to see where this discussion of labels goes.
>It's clear that there are some use cases not well-covered by our
>current feature set. However, in the meantime, this might be a
>workaround that can carry people through to the day when we do have
>some better solution (don't know whether that's 1.1, or 2.0, or later).
>
>
But how would I alter a property value "post-facto". Normal roperties
are only changed with a commit, which change the revision number. I
think that your first thought is the one that most resembles what we are
needing here. I think these "labels" should not be part of the "normal
time dimension", but instead bring some of the CVS' "4th dimension" to SVN.
And even so, we would need the tools to access these properties, we'll
need to have easy access through TortoiseSVN, and to be able of seeing
all the "labels" a file has, etc... All of this seems too far away in
the future. =(
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 2 17:27:19 2004