>Nicolás Lichtmaier <firstname.lastname@example.org> 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).
Instead of all this speculation, they should just fire their "CMM
expert" who's selling them an _implementation_ of the CMM model that was
probably designed for use with ClearCase, instead of designing the
implementation to suit the tools.
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Apr 2 23:06:41 2004