On Jan 30, 2005, at 3:42 AM, [EMAIL PROTECTED] wrote:
Paul Sander <[EMAIL PROTECTED]> writes:
On Jan 28, 2005, at 9:34 AM, [EMAIL PROTECTED] wrote:
Sergei Organov wrote:
Paul Sander <[EMAIL PROTECTED]> writes:On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] 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" [EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C.
_______________________________________________ Info-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs
