On Friday 22 October 2004 13:57, Scott Palmer wrote:
> On Oct 22, 2004, at 1:41 PM, John Szakmeister wrote:
> > David F. Newman wrote:
> >> On Fri, 2004-10-22 at 06:10, pushok wrote:
> >>> With your approach there NO difference between TAG and BRANCH.
> >>> All that is the COPY. One copy, called TAG we _promise_ do not
> >>> change. And
> >>> that's why it is a TAG. But nothing can prevent me from modifying
> >>> this
> >>> COPY. So, some "bad" developer CAN change the TAG.
> >> One can force a read-only policy on tags by making the /tags
> >> directory read-only to everyone except the release coordinator using
> >> mod_authz_svn. Then a bad developer can't change tags.
> > This can also be forced by using a pre-commit hook script. I made
> > one that allows you to create a tag, but you can't commit any changes
> > under it.
> In other words, you had to write your own code to work around the lack
> of this feature in subversion. :)
On the contrary, Subversion is so flexible, that I can make it do what I
want with hook scripts. :-)
> I would think that subversion could support some sort of standard
> property that indicated "this copy is a tag" and then it could enforce
> the immutability of that copy in some way.
Perhaps one day. You aren't the first person to mention having such a
thing. Personally, better branch support (seeing where files have been
copied to), and merge tracking are of much more concern to me.
> For ease of use the svn copy command could have a flag to say I'm
> making a "tag" copy, and the "tag" property would automatically be set
> on the copy.
What's so hard about svn cp http://.../trunk http://.../tags/1.0?
I know what you're getting at, you'd like to see built-in support for
tags. But I see it from a different view point, the scripts allow me to
set up my own policy for tags. I'm not restricted to what the developers
think is a 'tag'.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Oct 22 20:32:27 2004