Malcolm Rowe wrote:
> On Tue, Feb 13, 2007 at 11:58:07AM -0800, Blair Zajac wrote:
>> I think we would still want to force a way for a pre-commit script to
>> reject a client using file:///.
>>
>
> file:/// clients, by definition, can do anything to the repository,
> including corrupting it beyond all recognition. Adding any kind of
> security to ra_local is basically not going to work - the client is
> responsible for enforcing it.
I don't see anywhere that we treat file:/// by definition any different
than the other protocols. Clearly, you would want to use svn:// or
http:// to be safer, but there are some shops that go with file:///.
> But, really, what are we trying to fix here? The problems caused by
> someone committing using a non-merge-tracking client? Assuming you have
> any kind of post-commit review, you should spot the problem immediately.
That's assuming you have a well run organization. I am aware of larger
organizations where many people don't know how to use svn well or where
there aren't reviews and then only after the fact, do you have to clean
up. I would rather be safe than sorry. Better some up front work than
clean up a mess later.
> Even if not, once you've spotted the problem (I'm assuming the symptoms
> would typically be a repeated merge, so you'd probably get a conflict
> merging to the branch), you can just fix it using the 'svn merge'
> equivalent of svnmerge.py's --record-only option.
>
> You can also tell people "Don't do that". I find that frequently works
> a lot better than constructing a technical solution.
Again, work after things are messed up. I would rather just have an
easy solution that I don't have to think about it later.
I don't see it hard having the svn client provide an environmental
variable that the pre-commit script can look for the existence of.
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 14 22:01:39 2007