[Top][All Lists]

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

Re: CVS diff and unknown files.

From: Paul Sander
Subject: Re: CVS diff and unknown files.
Date: Sun, 30 Jan 2005 14:00:56 -0800

On Jan 30, 2005, at 3:42 AM, address@hidden wrote:

Paul Sander <address@hidden> writes:

On Jan 28, 2005, at 9:34 AM, address@hidden wrote:

Sergei Organov wrote:

Paul Sander <address@hidden> writes:
On Jan 27, 2005, at 1:07 AM, address@hidden wrote:
If "cvs add" will only warn about the problems, -- that's
OK with me as a user.

Actually, the way I see the situation is it only prevents the add if you
have requested the check with -c, if you have not used -c there is no
connection to the server and therefor can be no warning or prevention.

Actually, to err on the side of safety (which I define as policy enforcement in this case), I recommend that the trigger be enabled by default. The power users can turn it off in their .cvsrc files. I have two reasons for this: The first is that they're the ones who express an opinion and there are fewer of them than there are "ordinary" users, and the second is that they're the
ones most capable of making the change in their own environments.

The fundamental problem with your approach is that policy enforcement at
the client side is not CVS business. You still didn't explain what's
wrong with writing your own scripts on top of CVS to enforce whatever
policies you wish on the client side, or, if there is nothing wrong
about it, how CVS prevents you from enforcing whatever policies you need
on the client side.

I agree that there's a limit beyond which CVS should not interfere with the user. The user should, for example, be able to use whatever tools in his workspace as he deems necessary, provided it interoperates with rest of the methodology. Creating and deleting files in the workspace is clearly within the user's purview. However, as soon as the user declares an intent to store a file in the repository, he begins to subject himself to the policies of the project. Sooner or later, before he commits his work, he must comply.

Granted the time between "cvs add" and "cvs commit" is kind of a grey area, and the scope of add-time policy enforcement is pretty limited. (Access control and naming conventions are pretty much all you can do at that point. Arguing that it's reasonable to check the content of a file (for example) at that point is bogus, in my opinion.) But for those things that are reasonable to check, adding to CVS the ability to check them is totally reasonable.

On this point I seem to be getting overruled because most of the
members of this group are power users and don't adequately represent
the end user community.

It seems you miss the point, at least my point. I in fact don't care
much if -c is default or not provided CVS still allows me to add
files to the working copy offline. I care about it as a (hopefully
rather experienced) programmer that immediately sees fundamental
deficiencies in the underlying design. Not being CVS designer I don't in
fact care about it that much either, -- just tried to explain an
alternative design that I believe is better.

The add-time trigger proposal accommodates your requirement to have "cvs add" complete successfully when working offline. In your case, detection violations of add-time policy would be deferred until commit time, and you might be forced into some significant rework. You're clearly willing to take that risk and pay the cost, and that's your prerogative.

In my opinion, having the user run "cvs -n commit" right after "cvs add" is not at all a better solution to this particular problem.

Paul Sander       | "To do two things at once is to do neither"
address@hidden | Publilius Syrus, Roman philosopher, 100 B.C.

reply via email to

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