info-cvs
[Top][All Lists]
Advanced

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

RE: .cvsignore file being ignored


From: Alexandre Augusto Drummond Barroso
Subject: RE: .cvsignore file being ignored
Date: Thu, 5 Jun 2003 15:45:52 -0300

Sometimes we need to protect some users from themselves.
Usually I don't do what I'll describe here with regular IT 
users, but I have an exception: non technical users that 
creates docbook documents in the company I work for. 
The only thing they know is to click buttons in a specified 
order. 
If they do something different, they just don't know how to 
proceed (and usually don't even know witch button they 
pressed before something goes wrong). These days this kind 
of user is rare but they still exist. For this small group 
of users I use to create specific configurations and scripts 
(altering CVSROOT module's files like commitinfo, taginfo, 
and so) and I use to create macros to minimize user 
interface interactions and to avoid errors.

But I advise you to use this approach just for this almost 
extinct specie of end user.

Regards,

Xandao.

> -----Original Message-----
> From: Greg A. Woods [mailto:address@hidden
> Sent: Wednesday, June 04, 2003 9:58 PM
> To: CVS-II Discussion Mailing List
> Subject: Re: .cvsignore file being ignored
> 
> 
> [ 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
> anything.
> 
> 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>
> 
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
> 




reply via email to

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