Re: .cvsignore file being ignored
We should have been happy with running make distclean before running cvs import. (snip) find . -print | xargs rm We use cvs in our IDE for the customers. Upon creation of a project there are already many source files from the (embedded) OS. These files are already precompiled as a convenience for the users as they take much time to compile. Just imagine you'd have to compile first the whole MFC every time you make a new VC project. As the IDE knows all files which are in this project it's not a big problem to call cvs with every filename separately, even for seemingly recursive operations. So I don't have to rely on import or add to ignore some files. But still when I can use them I do. But deleting all the object files just for some big cvs command and then recompile everything again is not an option. I wouldn't have a problem with that, I often do recompile everything. But for the end users it wouldn't take long for them to start complaining about it. (Alexandre Augusto Drummond Barroso:) The only thing they know is to click buttons in a specified order. (snip) But I advise you to use this approach just for this almost extinct specie of end user. Extinct? You wish! We need to deal with them all the time. No, we can't teach them as they don't want to, they just want the software to behave as they expect. And as we rely on them as paying customers we have to try to do it their way. I can understand the objections against cvs add using the ignore list from a technical POV. I also often have to thell the users that this and that is difficult to do or not possible at all. But from the user POV this new behaviour would be more consistent and understandable. Cvs ignores everything in the ignore list, ALWAYS. I also ran into problems when I started to use cvs, I just have learned since then that it's not so. bye Fabi ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored
Kaz Kylheku writes: This is as it should be. The TYPES file represents the project's policy; some random user command should not override that policy. If we don't want .exe files in the repository, the add command should defend that decision for us, even if weakly. I happen to disagree, strongly. Repositories are not homogeneous -- you may not want executables in your module, but I want them in mine. And file name suffixes are not unique and reliable indicators of a file's type. My .doc files are plain text, thank you very much, not MS Word documents. There's nothing I hate more than software that thinks it knows more than I do and refuses to let me do what I want to do. -Larry Jones Somebody's always running my life. I never get to do what I want to do. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored...
On Wed, Jun 04, 2003 at 02:19:44PM -0700, Peschko, Edward wrote: [ Larry Jones wrote:] Damn straight. If you want software that thinks it knows more than you etc... But that goes contrary to the dictum there's more than one way to do it. Umm, you've got the wrong Larry :-) No way is that expression generally accepted computing wisdom. It's just a summary of the philosophy (to use the term rather loosely) behind Perl's design (or rather, lack thereof). -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored
At 10:08 AM 6/5/2003, Larry Jones wrote: There's nothing I hate more than software that thinks it knows more than I do and refuses to let me do what I want to do. The principal of least surprises should be Commandment #1 of the Software Engineers Ten Commandments (requirements for the other nine are still being collected :-) I agree that cvs add does just what it should do, but I can understand the desire for a cvs add-with-ignore command. It wouldn't be too hard to write a shell script cvs-my-add that trimmed the list of files on the command line based on the contents of ./.cvsignore and called cvs add. In order to get the build-in list and the $(CVSROOT)/CVSROOT/cvsignore list, you would have to do ugly things in a shell script, or build a new command into cvs. The current list of CVS maintainers does not seem to have the inclination to do this. Hey, it's Open Source. If you want it bad enough, you can add it. If you make it a separate command (or possibly enabled with a special option to add), then there's a chance it might be accepted by the current maintainers for the next release. I think that there's some file named Hacking or something like that which has requirements for getting something into cvs. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: .cvsignore file being ignored
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:[EMAIL PROTECTED] 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
Re: .cvsignore file being ignored
Peschko, Edward writes: Why the resistance to what would be a trivial feature? Because even trivial features are expensive. They clutter up the code, the test suite, the documentation, and the users' minds. In this case, it encourages a bad, some would even say dangerous, habbit (expecting software to second guess you and do what you want instead of what you told it to do). -Larry Jones I like maxims that don't encourage behavior modification. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored
If we don't want .exe files in the repository, the add command should defend that decision for us, even if weakly. I happen to disagree strongly . . . There's nothing I hate more than software that knows more than I do.. etc. etc. etc But that's what I don't understand. The idea behind .cvsblock (or TYPES or whatever) is to be able to *customize* the software to be able to exclude files. You don't need to use it! If you've got directories where you know what you are doing, put a blank .cvsblock file in it! Why the resistance to what would be a trivial feature? Ed ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored
[ On Thursday, June 5, 2003 at 11:42:37 (-0700), Peschko, Edward wrote: ] Subject: Re: .cvsignore file being ignored But that's what I don't understand. The idea behind .cvsblock (or TYPES or whatever) is to be able to *customize* the software to be able to exclude files. What you don't understand is that this decision was made a long time ago. CVS already provides a way to *customize* the software to be able to exclude files. It's called the ignore list and it is customized with the .cvsignore file and the '-I' command-line option. However this particular choice of implementation requires that there be a way to explicitly track changes to specified files that would otherwise be ignored, and that is done with the cvs add command. If you want CVS to continue to ignore some of your files then don't add them! RTFM! You don't need to use it! You can not have it both ways. I.e. you cannot have an ignore list that blocks and a block list that ignores. The decision about how CVS works was made when the ignore list was chosen and now that's the way CVS works. Like it or lump it. If you really want it the other way around, and embedded directly in the main program instead of in some wrapper or front-end, then I humbly suggest you fork CVS, call your version SVC or something, and do it your way. CVS is free software, as in free speech. Why the resistance to what would be a trivial feature? It's not a trivial feature -- it is a complete and utter reversal of the current mechanism of handling file lists for cvs add. If you don't understand that then you must really not understand the full implications of wildcard filename expansion at the shell level. Why don't you try approaching your shell vendor and ask them to implement your feature for you at the shell level where you seem to want it to be? That way CVS will never see any filenames that you don't want it to see. Good luck. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored
On Thu, 5 Jun 2003, Peschko, Edward wrote: If we don't want .exe files in the repository, the add command should defend that decision for us, even if weakly. I happen to disagree strongly . . . There's nothing I hate more than software that knows more than I do.. etc. etc. etc But that's what I don't understand. The idea behind .cvsblock (or TYPES or whatever) is to be able I think that .cvsblock is silly; the tiny semantics difference between that and .cvsignore is not worth it. The cvs add command should ignore things that match .cvsignore, period. Those who disagree: what part of ``cvs'' and ``ignore'' isn't clear? An interactive error would be a reasonable compromise. The software notices that the user requested to add files which match the .cvsignore specification, and so brings up a menu: add this file anyway, skip it, apply this action to all the rest. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored
[ On Thursday, June 5, 2003 at 14:00:12 (-0700), Kaz Kylheku wrote: ] Subject: Re: .cvsignore file being ignored I think that .cvsblock is silly; the tiny semantics difference between that and .cvsignore is not worth it. The cvs add command should ignore things that match .cvsignore, period. Because it was decided long ago that cvs add would be how all files would be tagged for adding to the repository, including those that would otherwise be ignored by default. Those who disagree: what part of ``cvs'' and ``ignore'' isn't clear? What part of Do What I Say! don't you understand? CVS just does exactly, and only, what you're telling it to do when you give it a file or a list of files on the command line. Why should users have to jump through extra hoops just to cause CVS to do what they're trying to tell it to do in the first place? If you don't want to add a file then do not include its name on the cvs add command line! This basic UI decision is part of history now. Like it or lump it. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored
--- Forwarded mail from Greg Woods: [ On Thursday, June 5, 2003 at 14:00:12 (-0700), Kaz Kylheku wrote: ] Subject: Re: .cvsignore file being ignored I think that .cvsblock is silly; the tiny semantics difference between that and .cvsignore is not worth it. The cvs add command should ignore things that match .cvsignore, period. Because it was decided long ago that cvs add would be how all files would be tagged for adding to the repository, including those that would otherwise be ignored by default. I agree with the first part, but I don't believe that the second part was really considered by the designer and the implementation came out the way it did by default. Consider the use of cvs import, which obeys the .cvsignore file. From and end-user perspective, it's not unreasonable to expect the following: - CVS behaves the same way with regard to processing the .cvsignore file during both add and import. - CVS gives warnings or errors when a file named on the command line is omitted due to the .cvsignore file. Ideally, it would issue errors and leave the Entries file alone. - The cvs add command provides an option to ignore the contents of the .cvsignore file, just as cvs import does. Those who disagree: what part of ``cvs'' and ``ignore'' isn't clear? What part of Do What I Say! don't you understand? CVS just does exactly, and only, what you're telling it to do when you give it a file or a list of files on the command line. Why should users have to jump through extra hoops just to cause CVS to do what they're trying to tell it to do in the first place? Why should users jump through hoops just to have CVS not do something they don't expect? If users are told that CVS is configured to ignore .o, .a, and whatever types of files, then CVS should do just that. It should not just sometimes ignore them. If you don't want to add a file then do not include its name on the cvs add command line! Not a valid argument when wildcards or xargs are in use. This basic UI decision is part of history now. Like it or lump it. The fact that a feature is implemented in a certain way does not make it immutable. It can, and should, be changed if ease of use is increased, provided no utility is lost. Justifying a broken UI because that's just the way it works is nonsense. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored
[ On Thursday, June 5, 2003 at 15:23:16 (-0700), Paul Sander wrote: ] Subject: Re: .cvsignore file being ignored I agree with the first part, but I don't believe that the second part was really considered by the designer and the implementation came out the way it did by default. Actually it was. Search your list archives. Usually every time it's been discussed since people are much quicker to understand what Larry and I have been trying to say. Perhaps that's because previously more of those questioning this behaviour have had a deeper understanding of what wildcard filename expansion really imply to how command line interfaces work and how they must be used. Once upon a time I posted: CVS' add command, when used on a new file, tells the local working directory that the new file is source. The CVS ignore list can declare that a file is not source, *BUT* CVS is allowed to over-ride the ignore list. A known file will never be ignored no matter how many times or places you put it into the ignore list. I.e. cvs add and .cvsignore compliment each other. In other words the ignore list is _NOT_ used to control which files CVS acts upon. CVS always acts upon the files you tell it to act upon. The ignore list is used only to control which files _not_ warned about when CVS is operating in its normal recursive mode, since otherwise CVS would warn the user to take control of all the files it finds in the workspace. The purpose of the ignore list is quite explictly _NOT_ to prevent the user from telling CVS to treat a file as source which it would otherwise ignore but rather it is there only to prevent CVS from being too noisy about files it isn't already tracking in the repository. Consider the use of cvs import, which obeys the .cvsignore file. That's a historical artifact as well, though perhaps one that might be easier to change than with cvs add. If I'm not mistaken the ignore list feature was originally designed only to be used during cvs update. Conceptually its purpose is to deal with working directories whenever CVS is doing its own directory traversal. I'm not sure when exactly cvs import first honoured the ignore list, though with hindsight we can see that it should never have done so. Unfortunately things only got worse when .cvsignore files were honoured even when '-I !' is explicitly specified. See the manual for further discussion of this. If you recall my proposal to enhance cvs add you might remember that I suggested the new version would behave (with respect to directory names given as command line parameters) as follows, simulating cvs import to some extent, but at least fixing the documented bug in cvs import -I !: - cvs add dirname will recurse through the specified directory adding all new ``un-ignored'' files if the current directory, or one of the parent directories, is a valid CVS working directory (as above). (including if dirname == . || == ) - Nothing will be done if no new files are found to add. - cvs add dirname will honour the '-l', '-R', and '-I' Common Options just as every other command which operates recursively. - cvs add -I ! dirname will not ignore any files, not even those listed in any .cvsignore files, except of course all CVS administrative sub-directories and their contents. - If CVS (admin subdir's name) is specified explicitly it will be (silently unless -) ignored. - Variations of newfile, path/to/newfile, and dirname will be accepted simultaneously on the command-line (just as with other CVS commands). - no explicitly named file or directory will ever be ignored, even if it would be ignored by the current cvsignore list (i.e. -I ! is not necessary for explicitly specified names that would be otherwise ignored if they were simply implied by recursion) I was reluctant to write the proposal this way and gave in only for the case where the command line parameter is a directory name and thus would trigger recursive operation. We should have been happy with running make distclean before running cvs import. Why should users jump through hoops just to have CVS not do something they don't expect? Because you can't have it both ways The decision was made long ago and it has been happily accepted for many years now. Not a valid argument when wildcards or xargs are in use. Paul, please go back to basic unix school. I.e. learn to use your tools properly instead of abusing them! Meanwhile here's how you should remove all the object files in your source tree: find . -print | xargs rm Please try it out and let me know how it works. If you don't understand how and why wildcards work then don't use them! -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL
Re: .cvsignore file being ignored
Paul Sander [EMAIL PROTECTED] writes: Consider the use of cvs import, which obeys the .cvsignore file. Yes, that 'cvs import' obeys the .cvsignore file is somewhat broken. The '-I !' command-line option should be honored and should NOT process either local .cvsignore files or the global CVSROOT/cvsignore file), but it too late to fix it now... The big thing to remember that is different between cvs import and cvs add is that an import happens immediately while an add does not happen until the 'cvs commit' occurs and any time up until the 'cvs commit' you may remove files from the list of those that should not be committed. In an different world perhaps only the new directories would be added to the repository on a 'cvs import' and the import tree would become a sandbox with all of the files having been 'added' to the repository, but not yet committed. That different world might allow folks to make sure that their master repository still worked properly with all of the new imported files... Ah well, that is not this world today. The way that 'cvs import' works was made long ago and a change to it will not likely happen even though there is some merit in the fact that a cvs import may appear to do the 'wrong' thing when some files have local changes and others are unchanged after a cvs import occurs that makes some of those new files visible, but not all of them. (I am still pondering the order of an import versus work on a branch problem raised in a different thread.) In general, best practice would have you add a local change to all of the imported files so that nothing on your HEAD would change when you did the import until after you had merged all of the changes forward to the HEAD... not everyone likes that methodology, so that is probably not what folks do today... From and end-user perspective, it's not unreasonable to expect the following: - CVS behaves the same way with regard to processing the .cvsignore file during both add and import. In theory, a user can type 'cvs import -I !' and have *all* of the files imported... well, as long as they remove all of their .cvsignore files first and emasculate any CVSROOT/cvsignore files. How do you proposed that 'cvs add' users get ALL of they files they explicitly request be added to the repository added? Mind reading software is notoriously slow to get into production for some reason. - CVS gives warnings or errors when a file named on the command line is omitted due to the .cvsignore file. Ideally, it would issue errors and leave the Entries file alone. I find this idea of an interface to be ugly... - The cvs add command provides an option to ignore the contents of the .cvsignore file, just as cvs import does. Why should users jump through hoops just to have CVS not do something they don't expect? If users are told that CVS is configured to ignore .o, .a, and whatever types of files, then CVS should do just that. It should not just sometimes ignore them. This sounds like an education problem to me. If you tell them that whatever they put on the 'cvs add' command line will be added to the repository, and that is what the command does, won't they expect that behavior? CVS is NOT configured to ignore .o .a and whatever types of files. It is configured to suppress complaining about them when they are found in a controlled directory. --- Forwarded mail from Greg Woods: If you don't want to add a file then do not include its name on the cvs add command line! Not a valid argument when wildcards or xargs are in use. But the point is that any argument to cvs add is valid. That is what we have been saying all along... If I need/want to do cvs add lib-a-purchased-library.a to add a .a file obtained from a third party to my sources, why should cvs ignore that I have done this? The cvs command is not able to distinguish this from the cvs add *.a command in a directory which contains only the single lib-a-purchased-library.a file. This basic UI decision is part of history now. Like it or lump it. The fact that a feature is implemented in a certain way does not make it immutable. Certainly, the software is not immutable. You yourself have the sources and therefore the ability to do anything you wish to them. I have no problems with you choosing to do anything you wish to your copy of the sources and I encourage you to make the changes you believe will improve the product and deploy them into your environment for testing and production. Feel free to update your sources as often as you wish out of the cvshome.org repository or periodic source distributions. If your patch is particularly elegant and desirable, who knows, someone may add it to the repository for you. However, you may find your time is better used if you go and use Meta-CVS instead of vanilla CVS. It appears to already have the feature you desire and Kaz Kylheku has been very responsive to problem reports and keeping his extra
Re: .cvsignore file being ignored
Mark D. Baushke writes: The big thing to remember that is different between cvs import and cvs add is that an import happens immediately while an add does not happen until the 'cvs commit' occurs and any time up until the 'cvs commit' you may remove files from the list of those that should not be committed. No, the big thing to remember that is different between import and add is that add takes an explicit list of files to process whereas import does not. .cvsignore *never* overrides an explicit file specification by the user (nor should it), it only affects what files CVS processes when it's generating the list of files itself. -Larry Jones My upbringing is filled with inconsistent messages. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored...
No. A user should be able to add any file to the repository that they wish The .cvsignore file is to reduce the clutter on an update or diff I disagree. If I say 'cvs add * in a directory, I surely don't want to pick up extra files, like vim's .swp, and ~ files, or maybe .bak files, or whatever. If I *wanted* to pick up a file like this, there should be an option, like '--force'. Perhaps there should be another file called '.cvsblock' that filters files on the client side? Ed ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored...
Peschko, Edward writes [in long lines]: I disagree. If I say 'cvs add * in a directory, I surely don't want to pick up extra files, like vim's .swp, and ~ files, or maybe .bak files, or whatever. Then don't say that. Or follow it with a cvs rm *.swp ... to unadd the stuff that you didn't really want to add in the first place. But don't complain when CVS does exactly what you tell it to. -Larry Jones The game's called on account of sudden death. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored...
I disagree. If I say 'cvs add * in a directory, I surely don't want to pick up extra files, like vim's .swp and ~ files., Then don't say that. Or follow it with a cvs rm *.swp ... to unadd the stuff you didn't really want to add in the first place. But don't complain when CVS does exactly what you tell it to. But that's no good - its error prone, and it puts the onus on the user to get it right. If I'm a cvs administrator working with lots of newbies, I don't want them to clutter up the archive with a bunch of junk. That's why I suggested '.cvsblock'. Its simple, separate, solves a usability question and is newbie friendly. Experienced people (administrators) would create it, newbies wouldn't even know its there. And with true ACL, you could make it so only the administrator could change it, or maybe block it on the server side. Ed ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored...
Peschko, Edward writes [still using long lines]: But that's no good - its error prone, and it puts the onus on the user to get it right. Damn straight. If you want software that thinks it knows more than you do, Microsoft will be glad to oblige you. The philosophy here is that the user is in control and the software should do what it's told. When you create a file, you add it (note the singular); cvs add * is a mistake (if for no other reason than it also tries to add the CVS subdirectory). -Larry Jones The authorities are trying to silence any view contrary to their own! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored...
But that's no good - its error prone, and it puts the onus on the user to get it right. Damn straight. If you want software that thinks it knows more than you etc... But that goes contrary to the dictum there's more than one way to do it. You didn't comment on my .cvsblock proposal - Nobody's forcing a user to make a .cvsblock file, its up to you (or a cvs admin) to set it up, and use it. And if users want to override the .cvsblock, they could make a local copy with a ! in it... I don't understand, I'm not asking for a change in the current cvs behaviour, I'm asking for a (new) feature request (and a fairly benign one, at that). What's the big deal? Ed ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored...
[ On Wednesday, June 4, 2003 at 13:04:30 (-0700), Peschko, Edward wrote: ] Subject: Re: .cvsignore file being ignored... I disagree. If I say 'cvs add * in a directory, I surely don't want to pick up extra files, like vim's .swp, and ~ files, or maybe .bak files, or whatever. Regardless that's the way it pretty much must work at this point. If you don't want to explicitly add all the files then do not use any wildcard pattern that expands to any name you don't want to explicitly add! I hope you do realize that wildcard expansion is done by the shell, not the utility -- the invoked progam never sees any wildcard expression, just the resulting list of files. I hope you also know you can cvs rm all the files you had not intended to add before you commit and you'll know for sure that you've added files you didn't want to add at any time you see the list of new files to be committed (e.g. with cvs -nq update). It is extremely trivial to deal with any accidental cvs add. If I *wanted* to pick up a file like this, there should be an option, like '--force'. That would be minutely better than your next suggestion, but it's still really very unnecessary and would seriously break backward compatability of the command-line user interface. (Note too that cvs rm * and cvs rm -f have VERY different consequences and thus they started out with a much different interface behaviour.) Perhaps there should be another file called '.cvsblock' that filters files on the client side? Then who gets to mediate between that and the existing .cvsignore list? You can't have it both ways and it's far too late to change this kind of arbitrary UI decision in CVS now. You could try to write a wrapper for yourself that inverts the sense of things, by scanning through the ignore list and through the command-line list of flies, filtering out those from the command-line that match the ignore list unless --force was turned on, but such a thing would have to forever remain an easily distinguished wrapper to the existing command-line UI since other tools and users will always expect the existing UI. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored...
[ On Wednesday, June 4, 2003 at 13:41:14 (-0700), Peschko, Edward wrote: ] Subject: Re: .cvsignore file being ignored... But that's no good - its error prone, Ah, NO, it is definitely _not_ error prone! and it puts the onus on the user to get it right. If I'm a cvs administrator working with lots of newbies, I don't want them to clutter up the archive with a bunch of junk. cvs add is an action that happens only in the workspace and it is trivially undone. If your user's can't get it right before they cvs commit then you really need to re-train them and to do so quickly and vigorously! Even with the current hack of cvs add directory, adding unnecessary directories to the repository is not really much of a problem either. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored
On Wed, Jun 04, 2003 at 07:11:07PM -0400, Greg A. Woods wrote: [[ PLEASE DO NOT TRY TO RESPOND TO ME DIRECTLY WHEN YOU CC THE LIST, and if you do not want me to do so in return then set your reply-to header appropriately ]] It is not possible for me to set my 'reply-to header' appropriately. The only way I can see my email on my unix server is to forward it from @pge.com. Sorry about that, the only way I can post to the list is via my stupid exchange server. If you want either of these things changed, please contact the list administrator, and tell him to fix the problem with my email address. I've already done so, and he's looking at it.. but if others complained, I'm sure it would get fixed faster. Ed ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored
I hope you do realise that wildcard expansion is being done by the shell.. not the utilty... Of course I realize that. I hope you also know you can cvs rm all the files you had not intended... Of course I realize that. if I *wanted* to pick up a file like this, there should be an option like '--force' That would be minutely better than your next suggestion, but its still really very unnecessary and would seriously break backward compatibility... etc That's why I suggested a new feature. [about .cvsblock ] Then who gets to mediate between that and the existing .cvsignore list? No need for mediation. The point of .cvsblock would be to scan, and filter, arguments on the *client side* before they are sent to the server. Do the wildcard expansion, filter the arguments going to the server. Looking through the code, I already see you do filtering on the server side, for the possibility of people doing 'cvs add * (in src/add.c)'. Do it on the client side as well. .cvsignore does filtering on the server side. It explicitly passes back an Ignore statement based on what it finds in ignore, and the client doesn't print anything. Making the usage consistent would be easy, simple make a .cvsblock link to .cvsignore and you'll block the files that you ignore, and vice versa. I could see some issues if people had different .cvsignore and .cvsblock files, but caveat emptor - its an easily fixed problem if you aren't running cvs in quiet mode. The more I look at it, the more I see that this is a philosophical point of contention than anything else... This is a ADDITION not a CHANGE; it isn't an 'arbitrary UI decision' - if people would want to use .cvsblock, they could, if not they won't. Personally, as a cvs admin I don't want to maintain extra cvs wrappers. I don't want to clean up after newbies by saying 'cvs rm' all over the place... I just want the feature, would use it, and want the functionality bundled with the client so I don't need to install anything else. Ed ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored
On Wed, 4 Jun 2003, Peschko, Edward wrote: No need for mediation. The point of .cvsblock would be to scan, and filter, arguments on the You want it, you hack it! Meta-CVS works as you want. It has a TYPES file which can specify that files having a certain suffix ought to be added using a given CVS expansion mode, or that they should be ignored. This is honored for every file that is passed as an argument to ``mcvs add''. If you do ``mcvs add foo.o'' and .o files are to be ignored, nothing happens. This is as it should be. The TYPES file represents the project's policy; some random user command should not override that policy. If we don't want .exe files in the repository, the add command should defend that decision for us, even if weakly. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored
[[ PLEASE DO NOT TRY TO RESPOND TO ME DIRECTLY WHEN YOU CC THE LIST, and if you do not want me to do so in return then set your reply-to header appropriately ]] [ On Wednesday, June 4, 2003 at 15:48:58 (-0700), Peschko, Edward wrote: ] Subject: Re: .cvsignore file being ignored The more I look at it, the more I see that this is a philosophical point of contention than anything else... It was only a philosophical point of contention _before_ the ignore feature was implemented. Now it has been implemented, and it is cast in stone because it is a fundamental part of how the UI is designed to work. Like Larry has been trying to tell you: CVS does what you tell it to do. If you don't want it to do something then DO NOT TELL IT TO DO THAT THING! -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
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;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
.cvsignore file being ignored...
hm. I have a .cvsignore file in each of my directories with the following entry: *~ and yet when I say: cvs add file~ it happily accepts the file, puts it in for committing. when I cvs commit, it commits the file. umm... shouldn't .cvsignore block these entries from being even processed? Ed ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore file being ignored...
Peschko, Edward [EMAIL PROTECTED] writes: hm. I have a .cvsignore file in each of my directories with the following entry: *~ and yet when I say: cvs add file~ it happily accepts the file, puts it in for committing. when I cvs commit, it commits the file. umm... shouldn't .cvsignore block these entries from being even processed? No. A user should be able to add any file to the repository that they wish. The .cvsignore file is to reduce the clutter on an update or diff operation, not to prohibit those files from bein able to be checed into the repository. It is perfectly acceptable to have both .* and * in the .cvsignore file so that a user is never 'bothered' with a list of files in the directory that are not cvs controlled. This does not mean that no files should be allowed to be added to the repository. Enjoy! -- Mark ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
