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.
>
> 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
>
I should probably mention my strong bias in that I hold the
philisophical belief that good conventions are only good /because/ they
are conventions, and that attempting to build any type of enforcement or
even standard method of allowing enforcement tends to take away from the
goodness of the convention. (eg: standard forms of code indenting are
only meaningful because the option exists to not indent when that too is
meaningful -- please keep any replies to /that/ off the list. Perfectly
willing to have a flame war in my own mailbox without cluttering
everyone else's)
---------------------------------------------------------------------
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:29:00 2006