|
From: | Wu Yongwei |
Subject: | Re: Resend importinfo patch |
Date: | Wed, 29 Oct 2003 18:26:39 +0800 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) |
Mark D. Baushke wrote:
1) To avoid misuse. I once encountered a developer just trying to use cvs and importing an existing module. As CVS administrator I donot like it at all. Of course he should not do it, but it is better to prevent it for ever than to educate everyone, esp. when I am not his boss.There are reasons that having a importinfo trigger might be useful, one reason might be that only special approved patches are allowed tobe put into the trunk and cvs import might be able to blow past that requirement.However, this implies you also need to close down the 'cvs add' of a new directory and the 'cvs admin' of existing files. The exact
Of "cvs add" I always think so. Of "cvs admin" I am not sure: is there the group "cvsadmin" to limit the use of "cvs admin" commands? People feel the control is too coarse and want per-project control?
semantics of importinfo/admininfo need to be defined so that they make sense to allow the administrator to define a consistent policy.It has been suggested that might make more sense to have commitinfo called for both import and new directory add operations... that is another path that is possible and the only reason I lean slightly against it is that existing commitinfo triggers may not be well suited to handle these new duties.
My first intuition is also commitinfo. However, 1) I feel importinfo can be really useful in practice (assuming changing the interface of commitinfo is unwelcome); 2) we have already a working patch for importinfo and I do not see people volunteer to do what you suggested.
2) To restrict the creation of modules (and initial files therein).If you use the commands: cvs checkout -l -d dir .cd dir mkdir new-modulecvs add new-module you have just created a new-module top-level module on your server.
I must confess I do not know this way. However, I would rather call this a hack and even suggest prohibiting it on the serve side. If one developer in a company did this to work around the security mechanism, I doubt the management would consider firing him. At least it will never be considered "misuse"; I would call it "abuse".
Best regards, Wu Yongwei
[Prev in Thread] | Current Thread | [Next in Thread] |