Re: CVS diff and unknown files.

[Paul Sander]

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.