Re: I miss tags

On Mon, Sep 27, 2004 at 02:44:12PM -0600, Tom Mornini wrote:
> Yes, I agree 100% that it *might* be nice to have the ability to
> associate BUILD_xyz with a specific revision number. However, I
> do not believe for a moment that this capability, as useful as it
> may be, will reduce people's wishes for tags.

I agree. It definitely will not provide the
"attribute-like" functionality that many use CVS-tags
for. I think that functionality isn't really about
identifying a configuration, its juts about denoting some
(allegedly :) useful piece of information on a version,
or a file/directory, or a copy (branch or label).

I think those are a special case of "Properties" and
could likely be handled with that mechanism rather than
with the copy or a "revno-alias"

> *I Think* that what people find uncomfortable about copies is
> that the ADDRESS or LOCATION changes.

I'm not so sure. If we assume the copy is being used to
identify and reproduce a "configuration", then I think
what they are worried about is that "the name of the thing"
ALWAYS refers to the same set of things (the same name
always means the same configuration).

A copy is a living, evolvable thing. And unless/until
they have a way to make them sealed/frozen, that makes
them nervous.

But I think separate from that, for some at least, isn't
whether or not the thing is changeable; it is whether or
not the thing "rightfully" belongs (and should be viewed
together with) the other set of things in will show-up
with.

Kind of like on "Sesame street" when they show a picture
of several things and say "one of these things is different
from the others; one of these things just doesn't belong" :-)

> Others would say that keeping the feature set minimalist, and
> not cluttering it with useful, though technically arbitrary
> 'fixes' (which some may classify as crutches for some people's
> inability or unwillingness to adopt to a new conceptual model)
> may, over time, destroy both the technical and conceptual
> cleanliness of an inherently more powerful model.

And I feel the same way, except that I differ in what
corresponds to simplest, cleanest, and minimalist. I
think the other thing could be done in such a way that is
in fact simpler, and cleaner, and more minimal than the
current implementation. And that adding extending existing
functionality doesn't necessarily make the existing model
more complex, and in fact can even make the model simpler
if "factored down" to the right core-set of simple but
powerful primitives (two of which "copies" currently try
to combine into a single "primitive").

And for implementation (as opposed to concept :-) I even
think it could naturally fall out of the basic "filesystem"
model. In a typical filesystem, each node has certain
attributes or permissions associated with it (as in Unix
there are read-write-execute bits for each of user, group,
and rest-of-world). Each "node" in the repo that
corresponds to a branch or label already has some
access/permissions associated with it. And the existing
r/w/x meanings already would and could handily apply
to what is being asked for with regard to the visibility
of a "label", and the changeability or a branch or label.

That wouldn't even have to invent much of anything new,
just use whats already there with a meaning that makes
sense for "metadata" nodes like branches/labels (as opposed
to user files and directories :-). Its not adding new
concepts so much as reusing what is already there, and figuring
how it can meaningfully apply in a way that hadn't necessarily
been realized yet (so instead of the concepts and their
functionality being new, what instead happened is existing
concepts were successfully translated into a new frame/context)

-- 
Brad Appleton <brad@bradapp.net> www.bradapp.net
  Software CM Patterns (www.scmpatterns.com)
   Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org