On Oct 22, 2004, at 3:43 PM, Mark Phippard wrote:
> Scott Palmer <scott.palmer@2connected.org> wrote on 10/22/2004 03:18:53
> PM:
>> I'm not suggesting anything is hard about it. I'm simply saying that
>> it does not result in a (reasonably) immutable copy.. which is *my*
>> definition of a tag, and there are obviously many others that have an
>> equivalent definition of what a tag should be.
>
> I am not aware of any version control tool that does not provide some
> way
> to alter tags after the fact. Therefore the immutable argument is a
> bit
> over stated. While some of the higher end commercial tools track
> changes
> made to tags, most of the common ones like CVS, PVCS and VSS do not.
I inserted the word "reasonably" for a reason. VSS uses "labels", you
can not get a labeled version, make a change and check it in and then
have the label refer to the new code instead of the old code, which is
precisely what will happen with subversion. Subversion "tags" are
fragile.
> Personally, I do not want immutable tags --
Understood. It all depends on the workflow you use and personal taste.
Subversion is touted as being flexible - but it is inflexible in the
sense that it does not offer much assistance to supporting an immutable
marker. The commit-hook idea seems to be the trick to making this
work, but it is essentially a workaround that must be applied on top of
a basic subversion install. That being said, perhaps it is not so bad
of a solution - I have yet to try it.
> What I think is the main issue is that it would be so easy for someone
> to commit
> changes to a tag by accident, without the tool doing anything to help.
That is exactly what I am concerned about. A naming convention in the
repository is too loose. Specially when you may not be aware of what
location in the repository your working copy is associated with. It is
easy to find out, but it is also easy no to check. "svn commit" doesn't
care, nor does it tell you where it committed to, so you may not find
out about a mistake that needs to be rolled back.
> Currently, this can be solved by using Apache and mod_authz_svn or by
> using hook scripts. I know that the developers have talked a lot about
> adding ACL's into the repository layer itself and I think this feature
> will likely come in a reasonable time frame. When that feature
> exists, I
> think it will be relatively easy to define permission's in the
> repository
> itself that create the "immutability" feature that some desire. Until
> then, you have to use hooks. I personally see no more problem using
> hooks
> for something like this, then I do with using hooks to send commit
> emails.
Sure. I hope it doesn't seem like I'm whining about this :) I'm just
trying to provide feedback so that when/if the feature is designed and
developed that this discussion will be here to draw upon for ideas.
> BTW, if you do the latter a nice benefit is you would be emailed if
> someone committed to a tags folder. So, in the event of an accident,
> the
> change can be reverted.
Good idea. though on windows all this stuff is a bit more of a pain.
> I think a nice idea might be to setup a "repository" of sample hooks
> that
> implement these ideas. There are some in the svn repository itself,
> but I
> am thinking something more "web-based" with accompanying documentation
> etc.. Kind of a Subversion "hooks" community. Maybe this would be a
> good
> Wiki-style app?
A great idea!
> It would also be nice if some of the hooks were then
> implemented in different languages so we did not all have to become
> Perl
> experts to use them.
I too prefer my code un-obfuscated.
> Anyway, this issue has been beaten to death in the last couple of
> months,
> so that is all I have to say.
yeah, I'm shutting up now too - unless I can't get the commit-hook
thing to work :)
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 22 22:23:24 2004