Jim Blandy wrote:
> On 2/22/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
>
>>How would people feel about some mechanism for stopping update reports
>>rooted at particular directories? It might at least prevent the
>>accidental foot shooting you get when an inexperienced user first
>>tries their hand at a svn checkout, and that would be a nice step in
>>the right direction.
>
> This seems to me like a pretty obvious hazard of the way Subversion
> repositories are laid out. I think it would make sense to have
> something which would help people avoid doing it by accident, as long
> as it didn't prevent them from doing it on purpose.
+1.
> Say, a property which makes 'svn checkout' print a message and get a
> confirmation interactively from the user, or pass a '--force' flag?
My first reaction was "Ooh, yuck, hacky" but in fact something like this, in
that it is detected and obeyed entirely at the client side, might well be an
appropriate solution. Skip to the end and you'll find I change my mind, but
meanwhile let's air some of the pros and cons and design choices.
CLIENT-SIDE
Normal Subversion properties cannot easily be applied to all revisions of an
existing repository, but on the other hand they are suitable in that the set of
protected directories might occasionally change from one revision to the next
(during tree reorganisations) and it's a good mechanism for getting centralised
information to the client.
Because a checkout is most commonly done on the head revision, there may be
little need to restrict checkouts of older revisions if the aim is to prevent
accidental misuse.
Therefore a property that says, "you really don't want to check out these
roots" for, typically,
/
/branches
/tags
(or the equivalent for each of the projects in the repository) could do the
job. As Jim suggests, the client should refuse to continue unless overridden
with some sort of extra confirmation. Of course, only new clients would do
this. Is that a problem? Perhaps it will be a significant problem in the
short term.
It would presumably be a single-valued property set on each path. It could
alternatively be implemented as a single property containing a list of paths,
but that seems to have only disadvantages unless we want to put it in a rev-prop.
The paths tagged should be those to be blocked, not those to be allowed,
because there are only a few high-level paths to be blocked whereas it is quite
reasonable to allow checkouts of any sub-tree of a project. People might say
sub-project checkouts don't make sense for their work environment and wish to
block them, but that's not the motivation for this feature and that requirement
would doubtless involve other things like blocking checkouts from certain
revision ranges.
One advantage of a rev-prop is that it can be retroactively applied to old
revisions of a project, but that doesn't feel like a great advantage. A
revprop doesn't automatically propagate to new revisions so a pre- or
post-commit hook would have to accomplish that. Another advantage is that an
existing rev-prop can be changed to reflect a new administrative policy.
This configuration is conceptually an administrative policy, and it bothers me
somewhat to have it stored in the repository as if it were a piece of the
project's history.
What IS a part of the project's history is the concept of certain directories
being project trees, others (lower) being project sub-trees, and others
(higher) being not project tree roots but part of the repository organisational
structure. Unfortunately this classification is not clear-cut, but, if we're
going to tag some of these directories with properties, it would be better for
the properties to have a meaning and a name that reflects the function of the
directory rather than trying to say directly what people should not do with it.
SERVER-SIDE
A server-side mechanism (e.g. pre-read hooks) has the advantage of applying
easily to all clients (types and ages), applying to all revisions, keeping the
administration separate from the project's content, and the ability for the
administrator to choose whether to enforce it or provide an override.
Disadvantages include not being so easy to provide an override.
Until I wrote that about the server side, I was thinking the client-side
solution was pretty good. Now I don't. Even though it's probably more
difficult to implement, I think a server-side mechanism is the right choice
because all of the advantages I listed for it are significant and important.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 23 03:05:40 2006