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.
As far as convention is concerned...well, there's a reason that many
sites adhere to this convention. It's a sound software engineering
principle. How useful is your source code repository (from both
engineering and legal standpoints) if its history is blurred by
check-ins on tags? I want to take a stand on this - and please DO
comment if you disagree:
I believe the fundamental concept of TAGS includes immutability. A
mutable tag, by definition, is a branch, not a tag. Furthermore, making
TAGS a first-class concept removes any need for mutability in tags.
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 21:57:44 2006