As someone who is looking forward to built-in merge tracking support,
I think having the technical means to control which client versions
can commit to the repository is very important. Without it, it will be very
easy for someone to accidentally use an out of date client, and this could go
unnoticed for some time. While this could be repaired after the fact,
I would much rather be able to take steps to prevent that. Without
being able to enforce
proper client versions the built-in merge tracking loses much of it's appeal, as
this is a recipe for having incomplete merge information.
I won't try to make another analogy about the tags dir, but in my environment
all tags would be suspect until verified if we didn't have a pre-commit hook.
Not being able to do similar things to protect the merge information would be
a big loss.
Roy
On 2/15/07, Peter Samuelson <peter@p12n.org> wrote:
>
> [Blair Zajac]
> > Malcolm Rowe wrote:
> > >Those two are orthogonal. Do you _really_ need the technical part if
> > >you've already established a non-technical policy?
> >
> > Policy is just policy, it doesn't enforce anything. We could have a
> > policy that nobody but committers is allowed to commit to our repository
> > and not have any authz, but we don't do that.
>
> That's a poor example, since we're actually talking about people who
> are already trusted in the sense that they have read/write access.
> People who can be kicked out, or fired, if they misbehave. A better
> example would be: "We could have a non-technical policy that certain
> committers are only allowed to commit in certain areas, documented in a
> file like COMMITTERS, and _not_ enforce it with authz."
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 16 00:57:25 2007