[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Resend importinfo patch

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 do
not 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 to
be put into the trunk and cvs import might be able to blow past that

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-module
   cvs 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]