Re: Svn hooks pre-commit - How, for tag operation, check than user make the tag operation in tags directory

On Tue, Sep 8, 2009 at 11:44 AM, Stefan Sperling <stsp_at_elego.de> wrote:

> While a wrong/deleted/modified tag is always a problem caused by human
> error, I'm beginning to doubt that we can keep telling people to simply
> be really, really careful, forever.
>

Actually, I agree with you. There is a lot in Subversion where we simply
tell users to be careful, and that's not a good attitude.

If I understood the question the user had, it was "how can I prevent tags
from being written to the wrong directories. Unfortunately, in Subversion,
there is no real way since tagging operations are similar to branching and
simply copying or moving directories. Is it a tag or is it a copy? We call
it a tag if its in the tag directory.

However, I don't think people carelessly do tagging operations. They may
simply decide to create a tag in another directory because it is convenient.

The big problem I have is that Subversion simply doesn't have the concept of
tags. We pretend that Subversion does tagging just like we pretended we
could tag files in SCCS. It is a work around, and a messy one at that.

Because of the lack ot tagging, comparing two tags is a mess:

$ svn diff http://subversion/dev/modules/adsuite/tags/ADS-5.4
http://subversion/dev/modules/adsuite/tags/ADS-5.5

If Subversion had tagging, we could have done this:

$ svn diff -rADS-5.4:ADS-5.5 http://subversion/dev/modules/adsuite/trunk

Or, more likely:

$ svn diff -rADS-5.4 .

Even worse, there is no concept of locking a tag. Tags are suppose to be
trusted snapshots of what my revision looked like at a certain moment in
time. To make sure tags aren't modified, most revision control systems let
you lock a tag to prevent someone from modifying it. In Subversion, you can
checkout a tag like you can any other directory, you can make your changes,
and you can commit those changes.

When I first used Subversion back in version 1.2, I was shocked by this. The
pre-commit trigger at that time allowed you to lock a directory to prevent
users from modifying it, but if you did that, users could not make tags. To
get around this, I ended up writing my own trigger that allows you to add a
directory to a particular location in the repository, but won't let you
commit changes to that directory. Thus, once you create a tag, it is locked.
I believe the current Python pre-commit trigger now does this.

But, that is still a stop gap measure. Tags should have been a built in
concept from the get-go. Occasionally, there is a discussion on this mailing
list about the lack of true tags. One recommendation is to make tags aliases
of revisions, so where you use a revision number, you could use a tag to
represent that revision. You'd need some commands to create these revision
aliases, more commands to lock them, and even pre-tag/post-tag hooks to
allow you to define what a tag can and cannot look like.

Most people and even the developers seem to agree with this approach, but
because we do have the ability to sort-of emulate tags, because of the need
to completely architect this new feature, because this feature would entail
changes in the server side and in the client side, and because of the
extensive restructuring of the Subversion data structure this might entail,
the idea of adding true tags to Subversion takes a backseat to more
important demands (performance, bug fixes, improvements in behavior, etc.)

If Subversion really didn't have any way to emulate tags, then we might have
seen some movement, but since we have a sloppy way to handle this, no
further work is done on it.

I don't think the existing solutions with pre-commit hooks are reliable
> enough. svnperms.py isn't the answer for complex real-world repositories.
> Having to write regexes to match paths in huge multi-project repositories
> with directory structures which happen to have evolved over time isn't
> that much fun.
>

I haven't had the pleasure of using svnperms.py. I understand it does a few
more things than the older Perl version of this script, but its structure
may be a bit more complex than what most people are looking for. I wrote my
own pre-commit trigger back in the 1.2 days that allows me to specify who
has commit access to the repository (read-only and read-write), and the
ability to create immutable tags (add-only), set properties, ban certain
file names and characters, and set templates for revision properties.

The big problem with a pre-commit hook, however, is that it is slow. Built
in permissioning would be much faster than running a script that has to read
in a control-file, parse it, and finally parse the user changes and see if
they match what you thought you put into the control-file.ini file..

-- 
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392558
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].