[Top][All Lists]

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

Re: .cvsignore file being ignored

From: Greg A. Woods
Subject: Re: .cvsignore file being ignored
Date: Wed, 4 Jun 2003 20:58:28 -0400 (EDT)

[ On Wednesday, June 4, 2003 at 16:34:23 (-0700), Peschko, Edward wrote: ]
> Subject: 
> It is in the sense that you are forcing people to do extra work.
> Extra work == extra possibilities for error. 

You simply cannot ever stop users from causing themselves extra
problems, no matter how much you might want to try.

You can only train them as best as possible and hope that the training
sticks or eventually catches on.

> argh. people do "cvs add *" all the time.

I personally don't know of anyone who does "cvs add *" all of the time
and without understanding that it will do exactly what they tell it to
do.  (That's not to say that people who I know don't do this sometimes
and without the outcome they expect -- but I've never observed anyone
doing this after having done it once and learned that it's not the right
thing to do, just like "rm *" is rarely the right thing to do.)

If you do know such people then it is your duty to teach them to use
their tools more properly!

> Why not change CVS and let them do this

Because it's FAR too late for such a fundamental change.  You can't just
arbitrarily invert the way the UI and a key feature like the .cvsignore
file works in a widely used tool, especially when that tool is used by
other tools that you don't maintain!

Arguing various minor features, and discussing blue-sky ideas is one
thing, but if you really want to see the fur fly you just go ahead and
try actually making such an arbitrary change in tool like CVS and then
try getting the masses to use your new version!  ;-)

> if the administrator doesn't mind?

The "CVS administator"?  As in the manager of the CVS repository that
the user is using?  What do they have to do with any of this other than
maybe being partly responsible for the ignorance of their users?

> The 'trivially undone' part isn't the point.

Yes, it is the point, actually.

CVS does what you tell it to do.  If you change your mind then you can
always undo what you've told it.  With "cvs add *" the undoing is even
easier than with most other sub-commands because at that point nothing
has yet modified the repository and no permanent change has been made to

You can't stop the user from running "cvs add foo.temporary", but the
user can trivially run "cvs rm foo.temporary" without you ever knowing
about it.  The effect of and the undoing of "cvs add *" is _literally_
NO different, not one bit different.

If you really want to stop your users from doing stupid things with
filename wildcards then you should force them to use a shell that
doesn't support such "dangerous" features.  That is the only correct
solution to your problem which doesn't involve someone having to
actually LEARN something.  (Heaven forbid that anyone ever have to learn
anything about how their tools work!)

> The point is that 
> you are forcing people to go through extra hoops to get
> stuff done,

Nobody's forcing anyone to use wildcards or even to use shells that
implement wildcard filename matching.

The wildcard matching feature provided by many command-line environments
is one that helps people avoid having to go through extra hoops to get
stuff done.  If people are instead abusing this feature and thus causing
themselves problems then the right solution isn't to force everyone else
in the world to change how they do things, but rather to teach those few
users who are having trouble to either make more appropriate use of such
powerful features as wildcards; or else to avoid using features which
might not do what they want or what they intuitively believe.

The next thing I'm afraid you'll be saying is that "rm *" should always
warn the user that they're about to delete all their files.  Well, no,
that's just not how these things work.  Are you really sure you fully
and deeply understand the actual and implied consequences for users (and
more imporantly in this case the implications for application user
interfaces) of pattern-based filename expansion in the command shell?

> not DWIM.

On the contrary, CVS _is_ doing exactly what you mean!  If you're
confused about what you mean to do then that's not CVS' problem!

                                                                Greg A. Woods

+1 416 218-0098;            <address@hidden>;           <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>

reply via email to

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