Re: Undesirable Watch/Edit Behavior
Todd Foster wrote: I am not sure I agree with that. The act of doing a fresh checkout of that file (either via a new "checkout" or "update -C" or what-not) makes CVS forget that you are editing that file. "cvs editors" no longer returns you as an editor of that file (regardless of where you run it from - either the first or the second directory). Personally, I consider that a bug. I believe I have even seen a patch submitted to change this behavior thought I don't remember what the patch did. Yes, I'd forgotten about that bug and patch - thanks for the reminder. I just checked the NEWS file, and it doesn't look like the patch has been released yet. My apologies for the misinformation. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Undesirable Watch/Edit Behavior
That's pretty much by design. Each checkout is completely independent of any other checkouts, and CVS does not make any attempt to coordinate between multiple checkouts. Thus, CVS has not forgotten anything - if your users go back to the first directory, they'll find that it is currently "Edit"ed by them. -- Jim I am not sure I agree with that. The act of doing a fresh checkout of that file (either via a new "checkout" or "update -C" or what-not) makes CVS forget that you are editing that file. "cvs editors" no longer returns you as an editor of that file (regardless of where you run it from - either the first or the second directory). Personally, I consider that a bug. I believe I have even seen a patch submitted to change this behavior thought I don't remember what the patch did. Todd ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Undesirable Watch/Edit Behavior
[EMAIL PROTECTED] wrote: I've set up a CVS module with "cvs watch on" so that users have to use "cvs edit" to reserve files for editing. This works fine for serial editing of unmergeable binary files files. When users try to edit files already marked for editing by someone else they are told the file is unavailable for editing as expected. The problem that I've encountered is that if a user subsequently checks out the same module again to a different location (i.e. two different sandboxes for the same module) CVS forgets about any files that user marked for editing before the second checkout. Is this behavior by design or a bug? I'm using CVS version 1.11.1p1 on a Linux server? That's pretty much by design. Each checkout is completely independent of any other checkouts, and CVS does not make any attempt to coordinate between multiple checkouts. Thus, CVS has not forgotten anything - if your users go back to the first directory, they'll find that it is currently "Edit"ed by them. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Undesirable Watch/Edit Behavior
I've set up a CVS module with "cvs watch on" so that users have to use "cvs edit" to reserve files for editing. This works fine for serial editing of unmergeable binary files files. When users try to edit files already marked for editing by someone else they are told the file is unavailable for editing as expected. The problem that I've encountered is that if a user subsequently checks out the same module again to a different location (i.e. two different sandboxes for the same module) CVS forgets about any files that user marked for editing before the second checkout. Is this behavior by design or a bug? I'm using CVS version 1.11.1p1 on a Linux server? ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
