Re: I miss tags

On Fri, Sep 24, 2004 at 12:04:07PM -0700, H. S. Teoh wrote:
> On Fri, Sep 24, 2004 at 01:38:12PM -0500, Brad Appleton wrote:
> [...]
> > So should SVN get rid of its tags-as-copies? Of course
> > not. I don't think anyone is saying that. Should it adopt
> > a CVS-style tags instead? I'm not sure anyone is saying
> > that either. I think their just saying there is this other
> > use of tags as attributes/properties that is orthogonal
> > from tags-as-copies and I want to be able to do that too,
> > and I want to consider it separately in the UI as well
> > (whether or not the implementation does or not is
> > another matter :-).
> [...]
>
> In other words, you're essentially asking for "syntactic sugar" in
> dealing with tags, independently of how they're actually implemented?

I don't believe so. That would give an alternate UI to
an existing mechanism rather than provide the additional
mechanism and concept in a fashion that was orthogonal
to the original(e.g., the "attributes" would still have
to be swept under the rug of the other UI somehow).

I think they are orthogonal concepts. It just so happens
that an implementation of one can also do some of the
things of the other, but not in a way that is conceptually
useful/usable.

I think the first step would be to acknowledge they are
separate and useful concepts, that are useful enough to
each warrant their own term/name. Using separate names
to refer to separate concepts with separate intended uses
is a good start (even if there may happen to be a single
implementation that can do both, albeit with significant
bias toward one perspective)

So instead of calling both of them "tags", maybe
calling the "copies" (or baselines) and "properties"
(or attributes) is a good start. Maybe talking about
"revision names" versus "revision numbers" (and that
both are valid forms of revision "identifiers") is
another one.

That way we can talk about meaning and intent before
diving into implementation assumptions, So when someone
says "couldn't you just do that with a 'copy' as
follows"?) the answer is "I could, but that doesn't
seem to clearly express my meaning/intent because ...".
And when implementing it as a "copy" has unintended
side-effects (like creating a new entity in one part of the
UI versus another, or having the command line incantation
seem very counterintuitive or not very clear/expressive)
maybe it means that even tho it really can be implemented
as a copy, we acknowledge and accept that full result of
doing it that way isn't necessarily a suitable match for
what is being expressed (even if it functionally achieves
a seemingly equivalent effect).

And maybe it means there is perhaps really three mechanisms
needed instead of the existing single mechanism: an
elementary one that both share, and then two additional
separate ones which each add onto the elementary one in
a more conceptually suitable way.

Might that not still allow a clean and consistent overall
implementation and use while still providing both viewpoints
their validity?

-- 
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