John,
John Peacock <jpeacock@rowman.com> wrote on 04.03.2005 19:54:11:
> > Well, then you need a policy that forbids creating tags with names
> > reserved for future use. What would you do if someone accidentially
> > creates a tag named "release-2.5.1" if should've been "release-2.4.1"?
> > Then you have a useless nightmare of deactivating the hook script,
> > changing the tag (renaming the directory) and re-activating the hook
> > script.
> That's a management issue, not a software issue.
Just because it's a management issue doesn't mean there should be no
solution "down there". Referring to a specific revision is always correct,
and in some application (safety critical projects as mentioned) _that_ is
the point. It's not a question of firing the one who broke the tag, or
adding policies to the work flow.
> If this is your particular itch, feel free to start working up a spec
> for discussion. I doubt trying to bully the developers here into adding
> belt and braces[1] for a feature that most people manage through policy
> isn't going to work.
I think, eventually I should look at the code myself and see how things
happen now and how I would like them to happen in the future. There is
quite some documentation for the internal SVN flow not mentioned in the
book I have to read before.
My only concern is putting the "/!svn/bc/<REV>" stuff into an optional
"?r=" parameter. This would leave the whole repository part of the URL
intact so that it can be cut&paste to the CLI or whatever client.
Additionally, changing things at the client side, maybe the "?r=" could be
supported to enhance the "-r" switch for checkout and update.
> > That's what you have to do if you don't trust tagging operations.
>
> And here is the crux of your problem. _You_ don't trust your users to
> follow a policy (whatever it might be) and you want the software to
> protect you from your users. _We_ don't have a problem establishing a
> policy and whacking anyone who violates it. Since every tree change is
> versioned (modulo revprops), it is always possible to use other means to
> correct any violation (but it might be inconvenient).
Exactly, that's the crux. I don't want the software to protect me from the
users, a pre-commit or other hook policy would enforce such thing. Instead
the other way round: I don't want to make any assumptions on the behavior
of the employees or other people working with the repository except for
low-level repository access. And I can't make this assumption since
policies change over years, good employees come and bad ones go, but the
repositories might have to give back information for decades. That's why I
need the internal policy requiring that in a document a reference has to
include the specific revision number, not only the tag, to make absolutely
sure that what I mean now is the same as what others see in thirty years.
Concerning other means: First you have to actually _see_ the violation.
The best case is if you once see the violation, the worst is if you rely
on the policy but it's invisibly broken. For whatever reason.
> There are plenty of much more important (IMHO) features to get into
> Subversion before something like a flexible policy manager gets to the
> top of the list (locking, true renames, and foreward references, not to
> mention a SQL repository).
Of course, there is a lot to do, (not to mention merge tracking). To make
my point here: I don't request a policy manager! It's just having revision
selection in the URL for ease in documentation, that's all.
- Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 4 21:14:45 2005