Re: Do most people checkout read-only and use cvs edit?
Karr, David wrote: I'm not talking about locking. It's always impractical to check out with locks, in any SCM. I'm just talking about what happens in the user's client view. I was under the impression before that cvs edit just affects the file in the user's client view. Does this also lock the file on the server? cvs edit is purely informational and does few things: 1. makes the file writeable which helps in case if you have CVSREAD=yes, so all files co'd read-only 2. creates local copy of the original file into Base subdirectory on local file 3. creates an information in the CVS repository (I do not know where, maybe only in CVSROOT/history file) which helps other users to get this information, let say for coordination purposes Reverse for cvs edit is cvs unedit, which should be called at least once for every cvs edit command. Otherwise we sooner or later get the mess and this information gets unuseful. So the correct purpose and procedure of using cvs edit would be: 1. cvs editors file_or_directory_in_question 2. communicate with other editors in a way of what is going on and decide in a way does it and how does this all affect my intentions 3. cvs edit or back-off (and wait for better time) 4. if cvs edit: 4.1. do the job 4.2. cvs update file_or_directory_in_question to get the changes that the other editors did on the object 4.3. resolve eventual conflicts 4.4. cvs ci 4.5. cvs unedit file_or_directory_in_question Izo ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Do most people checkout read-only and use cvs edit?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Izo [EMAIL PROTECTED] writes: Karr, David wrote: I'm not talking about locking. It's always impractical to check out with locks, in any SCM. I'm just talking about what happens in the user's client view. I was under the impression before that cvs edit just affects the file in the user's client view. Does this also lock the file on the server? cvs edit is purely informational and does few things: On the whole, your post is excellent. I'll just add a few details here to help folks understand what is happening behind the scenes... 1. makes the file writeable which helps in case if you have CVSREAD=yes, so all files co'd read-only A file that has had 'cvs watch add foo.c' or 'cvs edit foo.c' done to it will be checked out by default with a umask that specifies read-only. 2. creates local copy of the original file into Base subdirectory on local file Yes, the local tree will have a CVS/Base/foo.c and an entry in CVS/Baserev of a pristine copy of the currently edited version of 'foo.c' whenever a 'cvs edit foo.c' command is given. This is primarily an optimization used for when a 'cvs unedit' is performed. Note: There have been discussions that it might be useful for some disconnected operations (or very low bandwidth connections to the server) to let optionally allow for a CVS/Base/file be created as a base for local 'cvs diff' operations as well as to do a better job of determining if a file is locally modified or not without sending the entire file to the server at the cost of consuming twice the diskspace for a given tree. 3. creates an information in the CVS repository (I do not know where, maybe only in CVSROOT/history file) which helps other users to get this information, let say for coordination purposes If the file is module/somedir/anotherdir/foo.c then the information is recorded in the repository in $CVSROOT/ module/somedir/anotherdir/CVS/fileattr which contains information about any watches or editors of files in both module/somedir/anotherdir and module/somedir/anotherdir/Attic (for files that are dead on the main trunk but alive on one or more branches). Reverse for cvs edit is cvs unedit, which should be called at least once for every cvs edit command. Otherwise we sooner or later get the mess and this information gets unuseful. A 'cvs commit' and a 'cvs release' of the module will also undo the 'cvs edit' operation. So the correct purpose and procedure of using cvs edit would be: 1. cvs editors file_or_directory_in_question 2. communicate with other editors in a way of what is going on and decide in a way does it and how does this all affect my intentions 3. cvs edit or back-off (and wait for better time) 4. if cvs edit: 4.1. do the job 4.2. cvs update file_or_directory_in_question to get the changes that the other editors did on the object 4.3. resolve eventual conflicts 4.4. cvs ci 4.5. cvs unedit file_or_directory_in_question The final step is not needed as 'cvs ci' will do an implicit unedit for the user and the committed file will once more be read-only if there are any remaining 'cvs watchers' on it. However, should the 'cvs ci' step not be done, the user should do a 'cvs unedit' if the tree is going to be long lived. In addition, users should get into the habbit of using 'cvs release' to remove a checked out tree instead of just removing it from the local disk. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFA7V2B3x41pRYZE/gRAqXzAJ9NBvHVz9DFemD1z3CHctziMf0U/wCgzfm3 FhGmMRsp9+42JsS6/4G5jfM= =ux5l -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Do most people checkout read-only and use cvs edit?
I have a question about how people use CVS. How common is it to always checkout and update read-only, and then use cvs edit when you start working on a file? Or, do people checkout read-write and never use cvs edit? I have always thought that modules should be checked out read-only, and cvs edit is only used when you start to work on a file. However, I'm getting the impression that that appears to be an alternative strategy, and even deemphasized. In fact, in the WinCVS interface, the cvs edit functionality is under the Trace submenu, hiding it from the first-level menu. Other SCMs use the strategy that I'm used to as the primary strategy (checkout read-only, and do a specific operation to put the file into edit mode). ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Do most people checkout read-only and use cvs edit?
On Wed, 2004-07-07 at 14:01, Karr, David wrote: Or, do people checkout read-write and never use cvs edit? Yup, that's what I do. Optimistic locking and all that sort of thing, you know... Yours, Tom ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Do most people checkout read-only and use cvs edit?
At 02:01 PM 7/7/2004, Karr, David wrote: Other SCMs use the strategy that I'm used to as the primary strategy (checkout read-only, and do a specific operation to put the file into edit mode). Not CVS. That C stands for Concurrent. You can find out what that means at http://www.loria.fr/~molli/cvs/doc/cvs-paper.pdf The cvs edit functionality was put in place to help people deal with files that cannot be edited concurrently. Note that there are some people on this list who think very little of that capability. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Do most people checkout read-only and use cvs edit?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi David, 'cvs edit' and 'cvs watchers' is something that was bolted on to cvs as a way to give advistory locking to cvs for files that are difficult to merge. In general, I never use it (other than to test that the feature still appears to work). I would guess that very few people will use it unless they have binary files or files that require very close cooperation to edit which makes it hard to use in the full 'concurrent' model that gives CVS its name. Your mileage may vary... -- Mark Karr, David [EMAIL PROTECTED] writes: I have a question about how people use CVS. How common is it to always checkout and update read-only, and then use cvs edit when you start working on a file? Or, do people checkout read-write and never use cvs edit? I have always thought that modules should be checked out read-only, and cvs edit is only used when you start to work on a file. However, I'm getting the impression that that appears to be an alternative strategy, and even deemphasized. In fact, in the WinCVS interface, the cvs edit functionality is under the Trace submenu, hiding it from the first-level menu. Other SCMs use the strategy that I'm used to as the primary strategy (checkout read-only, and do a specific operation to put the file into edit mode). ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFA7D843x41pRYZE/gRAve5AJ0XOKiTDQJCDOI2m3U0oKmJUTAPKwCg1LbY OxLBVuRUqUZvODqHPdHByKU= =15DI -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Do most people checkout read-only and use cvs edit?
We never use cvs edit. In my opinion, that negates the whole benefit of the C in CVS. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karr, David Sent: Wednesday, July 07, 2004 2:02 PM To: [EMAIL PROTECTED] Subject: Do most people checkout read-only and use cvs edit? I have a question about how people use CVS. How common is it to always checkout and update read-only, and then use cvs edit when you start working on a file? Or, do people checkout read-write and never use cvs edit? I have always thought that modules should be checked out read-only, and cvs edit is only used when you start to work on a file. However, I'm getting the impression that that appears to be an alternative strategy, and even deemphasized. In fact, in the WinCVS interface, the cvs edit functionality is under the Trace submenu, hiding it from the first-level menu. Other SCMs use the strategy that I'm used to as the primary strategy (checkout read-only, and do a specific operation to put the file into edit mode). ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Do most people checkout read-only and use cvs edit?
I'm not talking about locking. It's always impractical to check out with locks, in any SCM. I'm just talking about what happens in the user's client view. I was under the impression before that cvs edit just affects the file in the user's client view. Does this also lock the file on the server? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Copeland Sent: Wednesday, July 07, 2004 11:12 AM To: [EMAIL PROTECTED] Subject: Re: Do most people checkout read-only and use cvs edit? On Wed, 2004-07-07 at 14:01, Karr, David wrote: Or, do people checkout read-write and never use cvs edit? Yup, that's what I do. Optimistic locking and all that sort of thing, you know... Yours, Tom ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Do most people checkout read-only and use cvs edit?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karr, David [EMAIL PROTECTED] writes: I'm not talking about locking. It's always impractical to check out with locks, in any SCM. Hmmm... 'cvs edit' implies locking, so, your question asked all of us about 'locking' even if you did not know that was what you were asking. I'm just talking about what happens in the user's client view. This is not what your message suggested. I was under the impression before that cvs edit just affects the file in the user's client view. This is an invalid impression. A 'cvs edit' creates an advisory lock. Does this also lock the file on the server? Yes it does. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFA7GOp3x41pRYZE/gRArlBAJ42fM41f3JC3SzF6AZVZAF2vcpOzgCePrRX KnkNL45bavS+GeUT0KlQII8= =quKI -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Do most people checkout read-only and use cvs edit?
I don't believe the 'edit' does a lock on the server. Quoting Vesperman's book: The cvs edit command is used as part of the cvs watch family of commands. If a file is being watched, it is checked out to the sandbox with read permissions but not write permissions. The edit command sets the sandbox file as writeable, notifies any watchers that the file is being edited, and sets the user as a temporary watcher to be notified if certain actions are performed on the file by other users I did a quick check and a file that I did an 'edit' on did not show up with a lock using 'log'. Mark D. Baushke [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karr, David [EMAIL PROTECTED] writes: I'm not talking about locking. It's always impractical to check out with locks, in any SCM. Hmmm... 'cvs edit' implies locking, so, your question asked all of us about 'locking' even if you did not know that was what you were asking. I'm just talking about what happens in the user's client view. This is not what your message suggested. I was under the impression before that cvs edit just affects the file in the user's client view. This is an invalid impression. A 'cvs edit' creates an advisory lock. Does this also lock the file on the server? Yes it does. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFA7GOp3x41pRYZE/gRArlBAJ42fM41f3JC3SzF6AZVZAF2vcpOzgCePrRX KnkNL45bavS+GeUT0KlQII8= =quKI -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Do most people checkout read-only and use cvs edit?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 JGentilin [EMAIL PROTECTED] writes: I don't believe the 'edit' does a lock on the server. Why take it on faith when you have the source? Go and look it up if you wish. It is not much of a 'lock', but for many definitions of the term it is a 'lock' ... The 'cvs edit' is an advisory lock. Use the command 'cvs editors' to see who has the file locked. The 'lock' shows up as an entry in the repository in the CVS/fileattr file in the same directory as the file being locked. Anyone who has a 'cvs watch' on the file will cause the CVSROOT/notify script to be run when someone does the 'edit' functionality. Quoting Vesperman's book: The cvs edit command is used as part of the cvs watch family of commands. If a file is being watched, it is checked out to the sandbox with read permissions but not write permissions. The edit command sets the sandbox file as writeable, notifies any watchers that the file is being edited, and sets the user as a temporary watcher to be notified if certain actions are performed on the file by other users The 'notifies any watchers' part is the one that can get expensive. I did a quick check and a file that I did an 'edit' on did not show up with a lock using 'log'. This does not show the 'lock', try using 'cvs editors' for this purpose. I never said that the locks were 'secure' or that I suggest that anyone should consider using them without a good reason and a good understanding of what is happening. -- Mark Mark D. Baushke [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Karr, David [EMAIL PROTECTED] writes: I'm not talking about locking. It's always impractical to check out with locks, in any SCM. Hmmm... 'cvs edit' implies locking, so, your question asked all of us about 'locking' even if you did not know that was what you were asking. I'm just talking about what happens in the user's client view. This is not what your message suggested. I was under the impression before that cvs edit just affects the file in the user's client view. This is an invalid impression. A 'cvs edit' creates an advisory lock. Does this also lock the file on the server? Yes it does. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFA7H2i3x41pRYZE/gRAgupAKCYum8AxWR/Hp/ZqnK/f+5ZDRscpwCgpQtW hcyCB/UniYfQQSDpg+srF7o= =9Ss5 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
