RE: "cvs commit" features
It doesn't have to be so bad if it takes care of your "ignore" settings as well. I think such an option may be good, at least for someone who did a large re-org of the files in the project. However, I agree with Greg A. Woods that the place of such options is not CVS itself but rather wrappers of CVS or GUIs. Shlomo -Original Message- From: Mike Ayers [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 8:48 PM To: Reinstein, Shlomo Cc: '[EMAIL PROTECTED]' Subject: Re: "cvs commit" features Reinstein, Shlomo wrote: > Of course, a user can always use "cvs add" and "cvs remove" to add or remove > files, but these two options can help him/her make sure they didn't forget > to do this for some of the files. This is one of those things that might work really well, but only for certain development models. For instance, I am using a GUI based tool. It likes to create lots of files that may or may not need to be archived. I have experimentally determined that if I archive a certain set of them, then there seems to be no problems. Do I want CVS to pester me about the ones I'm not archiving every time I do a commit in that directory? No way! And just think what would happen if you inadvertently did your CVS commit without making clean first... Nannyware sucks. Optional nannying? Hmmm - doesn't the nannyware model *require* that the nagging not be optional? /|/|ike ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: "cvs commit" features
>>Of course, a user can always use "cvs add" and "cvs remove" to add or remove >>files, but these two options can help him/her make sure they didn't forget >>to do this for some of the files. > > This is one of those things that might work really well, but only > for certain development models. For instance, I am using a GUI based > tool. It likes to create lots of files that may or may not need to be > archived. I have experimentally determined that if I archive a certain > set of them, then there seems to be no problems. Do I want CVS to pester > me about the ones I'm not archiving every time I do a commit in that > directory? No way! In my application which takes the output of cvs the user can choose between add, remove and ignore the file. If ignore is selected the name is written into the .cvsignore file so next time cvs won't ask about it again. bye Fabi ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: "cvs commit" features
Reinstein, Shlomo wrote: > Of course, a user can always use "cvs add" and "cvs remove" to add or remove > files, but these two options can help him/her make sure they didn't forget > to do this for some of the files. This is one of those things that might work really well, but only for certain development models. For instance, I am using a GUI based tool. It likes to create lots of files that may or may not need to be archived. I have experimentally determined that if I archive a certain set of them, then there seems to be no problems. Do I want CVS to pester me about the ones I'm not archiving every time I do a commit in that directory? No way! And just think what would happen if you inadvertently did your CVS commit without making clean first... Nannyware sucks. Optional nannying? Hmmm - doesn't the nannyware model *require* that the nagging not be optional? /|/|ike ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: "cvs commit" features
[ On Wednesday, October 9, 2002 at 07:41:59 (+0200), Reinstein, Shlomo wrote: ] > Subject: "cvs commit" features > > 1. An option to make "commit" ask you if you'd like to get rid of files that > exist in the repository but not in your working directory, and possibly > specify on the command-line which files to remove (or have the "commit" ask > you for each file or for each file extension). If you're already writing wrapper scripts then one to do that is nearly trivial to write using 'cvs -nq update'. > 2. An option to make "commit" ask you if you'd like to add files that exist > in your working directory but not in the repository, and possibly specify on > the command-line which files to add (or have the "commit" ask you for each > file or for each file extension). Once again that's an almost trivial wrapper script to write. > Of course, a user can always use "cvs add" and "cvs remove" to add or remove > files, Indeed one can and one should. > but these two options can help him/her make sure they didn't forget > to do this for some of the files. No, not really. Think of the CVS sub-commands as verbs for your wrapper scripts and use them that way. You don't want complex verbs that confuse the meaning of what's really going on. -- 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
"cvs commit" features
Hi, We have written a set of Perl scripts that wrap around CVS commands and do some more stuff that is specific to our working environment. Someone suggested that I add two options to the wrapper for "cvs commit", and I was wondering if anyone has thought about adding these two options to CVS itself or to a GUI for CVS, or otherwise, if there are any problems with these options: 1. An option to make "commit" ask you if you'd like to get rid of files that exist in the repository but not in your working directory, and possibly specify on the command-line which files to remove (or have the "commit" ask you for each file or for each file extension). 2. An option to make "commit" ask you if you'd like to add files that exist in your working directory but not in the repository, and possibly specify on the command-line which files to add (or have the "commit" ask you for each file or for each file extension). Of course, a user can always use "cvs add" and "cvs remove" to add or remove files, but these two options can help him/her make sure they didn't forget to do this for some of the files. Thanks a lot, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
