Vincent Starre wrote:
> I really disagree strongly with the idea that tags are just hacked-on.
> Something being a natural side-effect of a well-thought-out
> implementation- that is, requiring /no further code to work/ is a good
> thing, something to be praised, not a bad thing.
I will admit that it's cool that tags CAN be implemented in terms of
existing code. I never said Subversion wasn't well-designed. I was only
stating that the concept of tags is important enough in version control
to truly warrant its elevation to first-class status. I still believe
this is true.
Let me give you an example from my current projects. I work for Novell
in the directory and identity spaces. In this domain, we can build
nearly all (relevant) concepts on the fundamental entry/attribute model.
We chose not to do so because the flexibility this affords would allow
people to do dumb things. (Incidentally, in the directory and identity
spaces, we call this a security hole.:) )
> As for immutability, while tags represent an area which is "not to be
> messed with", that's far from immutable. Certainly, there are some
> tags which shoulodnt be touched, but the vast majority of tags (that I
> use, as opposed to that exist in the repos) I use are in fact
> "mutable". That is, they are not to be worked on, but they certainly
> do not represent a /single/ point in time.
Understood. When I used the term immutable, I was referring to the
contents of a work area arrived at via a tag, not the tag itself.
Clearly, there are advantages to having tags be deletable, or movable.
> "built-in" support for immutability? Can't this be handled through
> locks? (and can't locks be triggered with a hook?)
Sure, and can't symbolic names for revisions be managed by putting a
file called TAGS at the root of your project that contains a simple
mapping of revision numbers to symbolic names? Of course, but no one
would call this an elegant solution - even after you showed them the
grep/sed hack. :)
> I would shy from any change which would attempt to make svn "aware" of
> the filesystem in a way which is not implemented through user-defined
> hooks. Perhaps what is really needed is a better framework for writing
> hooks? I'm sure such things already exist for all the major languages,
> so maybe what's really needed is to publicize such things more :)
Subversion is not only already "aware" of the file system, but for some
back-ends (Berkeley DB, for instance), it IS the file system. Besides, I
don't really believe that tags-as-a-first-class-concept is going to
intrude on the file system very much. This is really a database issue,
not a file system issue. If the file system you're referring to is the
client-side work area, then I should clarify that I never stated that
users shouldn't be able to modify their work area in any way they wanted
- I only said that Subversion would not allow comits from a work area
produced from a tag. Returning to my example above from the directory
and identity spaces - this is what I'd call "a dumb thing that people
might do".
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 20 23:00:09 2006