John Calcote wrote:
> John Peacock wrote:
>
>> John Calcote wrote:
>>
>>> Speaking of branches, I would also like to see tags implemented such
>>> that people cannot commit a change from a work area produced from a
>>> tag - under any conditions.
>>
>>
>> That is a _convention_ that many sites adhere to, but doesn't need to
>> be coded into the _application_ itself. There are at least a couple
>> of ways to enforce that on the server, with a pre-commit hook being
>> the most easily managed.
>
> It's really great that there's a way to make this work, but how is
> this different from the tag-file/grep/sed construct in my original
> post as a way of managing tags as symbolic revisions? I'm talking
> about TAGS being treated as a first-class concept in Subversion. Not a
> thing to be hacked in on the side with hook scripts. Let me back off a
> little and try to state it less harshly and more concisely. Subversion
> TAGS as a way of accessing immutable snapshots is a concept important
> enough to version control systems that they SHOULD be added to the
> application.
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.
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.
Example: Whenever we send code to Texas, we tag it. Texas isn't a
branch, because it always represents a state of Trunk. But it would be
pointless to have seperate tags for Texas-2005-11-02 and
Texas-2006-02-07 when calling a tag by the same name all the time works
much better, and the dates are automatically logged anyway.
I once had a vast array of branch-tags as well, but now find that I'm
less likely to forget to write a log message than I am to forget to tag
something.
Meanwhile, nobody will ever touch 2.0r19 (this is handled by a hook)
"built-in" support for immutability? Can't this be handled through
locks? (and can't locks be triggered with a hook?)
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 :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 20 22:23:51 2006