Nicolás Lichtmaier <nick@reloco.com.ar> writes:
> Yes, definitely. But there's more... imagine you have a deep hierarchy
> filled with document files (not code). And every such document might
> have lots of tags. How do I do that? Subversion tagging is designed
> for tagging whole trees, not for the simple per-file labeling you can
> do with CVS and ClearCase. CMM needs lots of tagging, and that tagging
> needs to be manageable. This creates a problem with the current
> subversion tagging model and its capabilities. Managing these tasks
> sounds like a pain with subversion.
I'm just irresponsibly thinking out loud here...
At first, I almost replied "You could set properties on the files, and
use the properties as you use tags." Then I remembered that the
properties would be carried forward to all future revisions of that
file, until deleted. That doesn't quite do what you want.
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).
-Karl
---------------------------------------------------------------------
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:03:21 2004