Re: cvs edit/commit problem
The purpose of "cvs edit" is to communicate to others that you intend to modify
and commit a file. Therefore, unless you really do intend to modify and commit
all files, "cvs edit *" is the wrong thing to do. Don't do that.
Instead, "cvs edit" each individual file as you figure out that you do intend to
modify and commit it.
Of course, there may be circumstances when you would want to do "cvs edit *",
but since they are exceptional cases, "cvs edit *" should not be common
practice.
As for the behaviour being a bug, this can be debated. If you search through
the archives for "namespace" you might find past threads on the topic. The gist
is that different CVS commands act on different namespaces (eg whether the file
is already in the repository, whether the file exists within the working
directory, ...).
IMHO, the namespace considered by "cvs edit" is incorrect ("cvs edit" should be
allowed on files that don't exist in either the repository or the working
directory), but the namespace for "cvs ci" is correct. This means that "cvs ci"
should definitely not "cvs unedit" stuff that hasn't really been checked in.
Noel
[EMAIL PROTECTED] on 2000.10.05 12:20:51
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: (bcc: Noel L Yap)
Subject: cvs edit/commit problem
I'm experiencing a problem with cvs edit and commit. First of all, we
have a watch on the entire repository and everyone has the CVSREAD
variable set so that checkouts come as read only. This forces all
developers to use "cvs edit" before editing a file. It is common
practice, however, to just do "cvs edit *" so as to edit all files in
the given directory. The problem is on checkin. Just typing
cvs commit (or)
cvs commit . (or)
cvs commit *
works correctly on files that have been modified, but if a file has
not been modified cvs will not run "cvs unedit" on the file. The
result of this is that it leaves the editible file laying around (and
it shows up on cvs editors), very undesirable behavior. Right now I'm
trying to just get people into the habit of always typing:
cvs commit; cvs unedit
This doesn't seem the best solution, though.
Is this a know bug in CVS? Is there a known workaround? Maybe some
insight? One solution I've been toying with is to write a directive in
the loginfo file to go through and unedit the checked in directory,
but the problem with this is that if the user intended to just commit
a single file it will unedit all of them. Furthermore, if no files
were modified then the loginfo doesn't seem to be run at all.
Oh, I'm running CVS 1.10.8 (client/server) on Solaris x86 2.7, if that
makes a difference.
Thanks,
+---[EMAIL PROTECTED]-+
| Richard Jennings Duncanhttp://www.isip.msstate.edu |
| Graduate Research AssistantInstitute for Signal and Info. Proc. |
| Mississippi State University Computer Science |
+-+
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Co. Incorporated, its
subsidiaries and affiliates.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs edit/commit problem
On Thu, 5 Oct 2000, Richard J. Duncan wrote: Is this a know bug in CVS? Is there a known workaround? Maybe some No it is not a bug. If CVS did this it would be a bad idea for the same reason that the directive to automatically unedit the file you suggested would be a bad idea. The known work around it to either: * only edit what you intend to edit (rather than cvs edit *) * explicitly unedit everything you edit I would suggest a combination. Edit only what you need and unedit everything you've edited explicitly. Editing everything in a directory may be convient for the person working on the files, but what if a second person wants to work on something the first person doesn't even intend to touch? The second person must wait until the first has released his/her edit for a file they weren't even using. So my first suggestion would be to use this routine: 1) cvs edit specific files 2) vi files 3) cvs commit files But if you must do a global edit * then: 1) cvs edit * 2) vi file1, ... 3) cvs unedit * 4) cvs commit This way the programer explicitly releases those files. You could even make a simple shell script that did those last two commands together. Garth ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs edit/commit problem
[EMAIL PROTECTED] on 2000.10.05 13:25:57 On Thu, 5 Oct 2000, Richard J. Duncan wrote: Is this a know bug in CVS? Is there a known workaround? Maybe some No it is not a bug. If CVS did this it would be a bad idea for the same reason that the directive to automatically unedit the file you suggested would be a bad idea. The known work around it to either: * only edit what you intend to edit (rather than cvs edit *) * explicitly unedit everything you edit I would suggest a combination. Edit only what you need and unedit everything you've edited explicitly. Editing everything in a directory may be convient for the person working on the files, but what if a second person wants to work on something the first person doesn't even intend to touch? I agree. The second person must wait until the first has released his/her edit for a file they weren't even using. This isn't true. Unless the team is using the "cvs edit -c" patch, nothing prevents multiple edits on a file. So my first suggestion would be to use this routine: 1) cvs edit specific files 2) vi files 3) cvs commit files Yes. But if you must do a global edit * then: 1) cvs edit * 2) vi file1, ... 3) cvs unedit * 4) cvs commit Yes. It should also be noted that "cvs unedit" (rather than "cvs unedit *") is sufficient, but not necessary, to do the job. "cvs unedit", like "cvs ci" will recursively traverse the working directory structure. This way the programer explicitly releases those files. You could even make a simple shell script that did those last two commands together. It just occurred to me that developers may "cvs edit *" in order to watch everything. If this is the case, then it would be better to use "cvs watch add *" than "cvs edit *". Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs edit/commit problem
[EMAIL PROTECTED] on 2000.10.05 14:28:01 The purpose of "cvs edit" is to communicate to others that you intend to modify and commit a file. Therefore, unless you really do intend to modify and commit all files, "cvs edit *" is the wrong thing to do. Don't do that. Ok, then take this situation. I see a problem in this file. I want to edit it so I type "cvs edit file1" Then with further investigation I see the problem is really in file2, so I do "cvs edit file2" and then make my changes in file2. Then I am done with editing all files in this directory and am ready to checkin, so I do "cvs commit" You should've done "cvs unedit file1" when you found out you weren't planning to commit it. You can do "cvs editors" to help figure out what files you have edited. Why does cvs unedit the file that was modified and not unedit the file that was not modified. Because the file that was modified was checked in. I think it would be extremely difficult (and possibly damaging) to have "cvs ci" see files that haven't been modified so that it can act on them. Doesn't this part of the interface seem brain damaged to anyone else? It used to to me. Then I came to the conclusion that "cvs ci" is meant to act on modified files only. Either change all the files or none of the files, but this half-baked attempt at unediting some files just leads to problems. I disagree. If the user really wanted to unedit all files, they should "cvs unedit" themselves. Changing the current behaviour breaks CVS for those who are used to doing: cvs edit file0 cvs edit file1 vi file0 # and modify it cvs ci vi file1 # and modify it cvs ci Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs edit/commit problem
[EMAIL PROTECTED] on 2000.10.05 14:28:01 Ok, then take this situation. I see a problem in this file. I want to edit it so I type "cvs edit file1" Then with further investigation I see the problem is really in file2, so I do "cvs edit file2" and then make my changes in file2. Then I am done with editing all files in this directory and am ready to checkin, so I do "cvs commit" Why does cvs unedit the file that was modified and not unedit the file that was not modified. Take this situation: I see problems in file1 and file2, so I "cvs edit file1 file2". I fix file1 and "cvs commit". Why should cvs unedit file2? I still want to make changes to file2. When I did the commit, I wasn't intending to commit file2, only file1. The basic principle is that cvs shouldn't be doing too much guessing about what I mean. It has to "guess" that I was committing the file I changed. It doesn't necessarily follow that I also meant to unedit any files I had put an edit on. If I wanted to that, I'd use "unedit" instead of "commit". Jerry ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs edit/commit problem
Why does cvs unedit the file that was modified and not unedit the file that was not modified. Take this situation: I see problems in file1 and file2, so I "cvs edit file1 file2". I fix file1 and "cvs commit". Why should cvs unedit file2? I still want to make changes to file2. When I did the commit, I wasn't intending to commit file2, only file1. The basic principle is that cvs shouldn't be doing too much guessing about what I mean. It has to "guess" that I was committing the file I changed. It doesn't necessarily follow that I also meant to unedit any files I had put an edit on. If I wanted to that, I'd use "unedit" instead of "commit". I would argue that in your situation you should type cvs commit file1 instead of cvs commit if all you want to do is commit the one file. When you run cvs commit with no arguments it runs on all files in the current directory, so shouldn't it do something to all files in the directory? It seems arbitrary that it operates on only modified files, do people really like this. So far I have seen a lot of "it is right because it is the way it is," not "it is right because it seems the proper interface." -Rick ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs edit/commit problem
"Richard J. Duncan" wrote: It seems arbitrary that it operates on only modified files, do people really like this. So far I have seen a lot of "it is right because it is the way it is," not "it is right because it seems the proper interface." I might argue the side for the existing implementation associated process simply because I'd be annoyed with anyone on my team that kept having me sent 20 individual emails because they didn't want to type out (or copy paste) a single filename before they started editing in some heavily populated directory. And then I'd get another 20 emails when they checked in their single file. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Funny noises are not funny. Funny noises are not funny. Funny noises are not funny... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs edit/commit problem
[EMAIL PROTECTED] on 2000.10.05 16:42:02 I would argue that in your situation you should type cvs commit file1 instead of cvs commit What if there were tons of files spread throughout the directory hierarchy? It seems arbitrary that it operates on only modified files, do people really like this. So far I have seen a lot of "it is right because it is the way it is," not "it is right because it seems the proper interface." It's the way it is 'cos "cvs ci" works the way it did when "cvs edit" didn't exist. IMO, it might require a rearchitecture of CVS to change this. Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
