[bug #23370] cvs watch will be wrongly cleared by cvs co by the same user

View: New views

5 Messages — Rating Filter: Alert me

	[bug #23370] cvs watch will be wrongly cleared by cvs co by the same user by Simon Goldschmidt :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message URL: <http://savannah.nongnu.org/bugs/?23370> Summary: cvs watch will be wrongly cleared by cvs co by the same user Project: Concurrent Versions System Submitted by: petoft Submitted on: Monday 05/26/2008 at 22:26 Category: Bug Report Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Release: Fixed Release: None Fixed Feature Release: None _______________________________________________________ Details: In the example below I will demonstrate that the cvs "locks" functionality will be wrongly cleared by CVS version 1.12.13, when the same user who did the lock (using cvs edit) later does a "cvs checkout" or "cvs export". Since such additional "cvs export" operations easily can be a part of daily operations it is a very destructive bug in CVS. Especially problematic it is for non-mergeable files, when a multi-site CVS work group is using "cvs watch on+cvs edit" to signal, who is working where. Operations as user "pto" who makes a watch+edit ----------------------------------------------- $ cvs checkout my_proj ... lots of check out lines... $ cd my_proj $ cvs watch on README.txt $ rm README.txt $ cvs update README.txt $ ls -l README.txt -r-r--r-- 1 pto pto 6 2008-05-26 23:41 README.txt $ cvs editors README.txt # No files will be shown since no files are locked $ cvs edit README.txt $ cvs editors README.txt # Good I can see pto is locking "README.txt" README.txt pto Wed May 7 06:43:15 2008 -0000 myworkstation /opt/cvsroot/my_proj Operations as another user "joe" -------------------------- $ cvs checkout my_proj $ cd my_proj $ cvs editors README.txt README.txt pto Wed May 7 06:43:15 2008 -0000 myworkstation /opt/cvsroot/my_proj # Good I can see pto is locking "README.txt" - no problems Operations as user "pto" -------------------------- $ mkdir MY_SECRET_PLACE_OR_SOMEWHERE_ELSE $ cd MY_SECRET_PLACE_OR_SOMEWHERE_ELSE $ cvs checkout my_proj $ cd my_proj $ cvs editors README.txt # WHAT THE... ??? - the lock on my_proj/README.txt is gone.... :-(( Note that the same problem exist when you replace the second "cvs checkout" with "cvs export" In the example above after "cvs edit README.txt" both $CVSROOT/my_proj/CVS/fileattr and my_proj/CVS/Baserev show that the file is being edited, after doing another cvs co $CVSROOT/my_proj/CVS/fileattr does not show the file being edited anymore but my_proj/CVS/Baserev does -> thus we have a mismatch. Change wish: ------------ The "correct" operation by CVS would be NOT to clear the CVS locks, when doing more than one "cvs co" or "cvs export" by the same user. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?23370> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ _______________________________________________ Bug-cvs mailing list Bug-cvs@... http://lists.nongnu.org/mailman/listinfo/bug-cvs
	[bug #23370] cvs watch will be wrongly cleared by cvs co by the same user by Simon Goldschmidt :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #1, bug #23370 (project cvs): I appreciate that most cvs users don't make use of cvs edit, however for those of us that do this bug is a real pain. We use TortoiseCVS in conjunction with WinMerge as a front end to cvs. Unfortunately the act of comparing historical revision changes on a file with WinMerge results in a checkout operation behind the scenes in a temporary directory, conseqently your cvs watch is cleared. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?23370> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ _______________________________________________ Bug-cvs mailing list Bug-cvs@... http://lists.nongnu.org/mailman/listinfo/bug-cvs
	[bug #23370] cvs watch will be wrongly cleared by cvs co by the same user by Simon Goldschmidt :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #2, bug #23370 (project cvs): it seems directly connected to this problem (posted to bug-cvs@... 2009-03-25 22:57 CET): Assume that sandbox 1 and sandbox 2 are two different directories e.g. for development and the other for testing. User A in sandbox 1: -------------------- $ cvs edit foo.txt $ cvs editors foo.txt foo.txt A Wed Mar 25 21:48:32 2009 -0000 serenity.petertoft.dk /home/A/foocvs1 User B -------------------- $ cvs update -A foo.txt $ cvs update -r 1.1 foo.txt $ cvs update -A foo.txt $ cvs editors foo.txt <as many updates as you want - no problems> foo.txt A Wed Mar 25 21:48:32 2009 -0000 serenity.petertoft.dk /home/A/foocvs1 User A in sandbox 2: -------------------- $ cvs update -r 1.1 foo.txt $ cvs update -A foo.txt $ cvs editors foo.txt ## NO LOCK on foo.txt - BUMMER - the lock should have been kept ## _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?23370> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ _______________________________________________ Bug-cvs mailing list Bug-cvs@... http://lists.nongnu.org/mailman/listinfo/bug-cvs
	[bug #23370] cvs watch will be wrongly cleared by cvs co by the same user by Simon Goldschmidt :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #3, bug #23370 (project cvs): This is severely impacting our workflow. Our group does a lot of development in graphical, model-based software tools, and those files cannot be merged easily. We rely heavily on cvs-edit commands, and the fact the the edits are being cleared is causing us lots of grief. I have attempted to create a workaround using the CVS scripting hooks, and I've got a solution that almost works, but doesn't quite make the cut. Here is an overview of what I've attempted so far. CVS stores the edit/watch info inside the repository in CVS/fileattr files for each directory in CVS. The "notify" administrative file allows programs to be run whenever a user performs cvs-edit or cvs-unedit. I was able to create a perl-script that was run via notify that created a copy of all fileattr files affected by the unedit or edit command. The fileattr files were copied into a "fileattribbackup" subdirectory of CVSROOT, which mimics the directory structure of the actual repository. The next step is to then copy the "backup" fileattr files stored in CVSROOT into the repository whenever a user performs a checkout, which can be performed by specifying the perl script to run in the "modules" file. Now, the problem I'm facing is that when my script is called from "notify", CVS has not yet modified the fileattr files, so the files that get copied into the CVSROOT backup area are basically 1-rev behind. This is my major roadblock at this point. Does anyone have better ideas of how to handle this? Another idea I was throwing around was to monitor all of the "fileattr" files for changes in a continuously running process, which would copy them to the backup location when they change. Then the checkout script could run as before. This seems like asking for trouble (at least more than the previous solution), because then I need to deal with cvs locks and such. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?23370> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ _______________________________________________ Bug-cvs mailing list Bug-cvs@... http://lists.nongnu.org/mailman/listinfo/bug-cvs
	[bug #23370] cvs watch will be wrongly cleared by cvs co by the same user by Simon Goldschmidt :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #4, bug #23370 (project cvs): I've attached a modified version of update.c, which was downloaded from the 1.11.23 sources. I've commented out 5 lines of code, which I believe are the culprit for this bug, (at least the comment directly above them indicates so).. (file #18988) _______________________________________________________ Additional Item Attachment: File name: update.c Size:86 KB _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?23370> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ _______________________________________________ Bug-cvs mailing list Bug-cvs@... http://lists.nongnu.org/mailman/listinfo/bug-cvs

	[bug #23370] cvs watch will be wrongly cleared by cvs co by the same user by Simon Goldschmidt :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message URL: <http://savannah.nongnu.org/bugs/?23370> Summary: cvs watch will be wrongly cleared by cvs co by the same user Project: Concurrent Versions System Submitted by: petoft Submitted on: Monday 05/26/2008 at 22:26 Category: Bug Report Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Release: Fixed Release: None Fixed Feature Release: None _______________________________________________________ Details: In the example below I will demonstrate that the cvs "locks" functionality will be wrongly cleared by CVS version 1.12.13, when the same user who did the lock (using cvs edit) later does a "cvs checkout" or "cvs export". Since such additional "cvs export" operations easily can be a part of daily operations it is a very destructive bug in CVS. Especially problematic it is for non-mergeable files, when a multi-site CVS work group is using "cvs watch on+cvs edit" to signal, who is working where. Operations as user "pto" who makes a watch+edit ----------------------------------------------- $ cvs checkout my_proj ... lots of check out lines... $ cd my_proj $ cvs watch on README.txt $ rm README.txt $ cvs update README.txt $ ls -l README.txt -r-r--r-- 1 pto pto 6 2008-05-26 23:41 README.txt $ cvs editors README.txt # No files will be shown since no files are locked $ cvs edit README.txt $ cvs editors README.txt # Good I can see pto is locking "README.txt" README.txt pto Wed May 7 06:43:15 2008 -0000 myworkstation /opt/cvsroot/my_proj Operations as another user "joe" -------------------------- $ cvs checkout my_proj $ cd my_proj $ cvs editors README.txt README.txt pto Wed May 7 06:43:15 2008 -0000 myworkstation /opt/cvsroot/my_proj # Good I can see pto is locking "README.txt" - no problems Operations as user "pto" -------------------------- $ mkdir MY_SECRET_PLACE_OR_SOMEWHERE_ELSE $ cd MY_SECRET_PLACE_OR_SOMEWHERE_ELSE $ cvs checkout my_proj $ cd my_proj $ cvs editors README.txt # WHAT THE... ??? - the lock on my_proj/README.txt is gone.... :-(( Note that the same problem exist when you replace the second "cvs checkout" with "cvs export" In the example above after "cvs edit README.txt" both $CVSROOT/my_proj/CVS/fileattr and my_proj/CVS/Baserev show that the file is being edited, after doing another cvs co $CVSROOT/my_proj/CVS/fileattr does not show the file being edited anymore but my_proj/CVS/Baserev does -> thus we have a mismatch. Change wish: ------------ The "correct" operation by CVS would be NOT to clear the CVS locks, when doing more than one "cvs co" or "cvs export" by the same user. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?23370> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ _______________________________________________ Bug-cvs mailing list Bug-cvs@... http://lists.nongnu.org/mailman/listinfo/bug-cvs
	[bug #23370] cvs watch will be wrongly cleared by cvs co by the same user by Simon Goldschmidt :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #1, bug #23370 (project cvs): I appreciate that most cvs users don't make use of cvs edit, however for those of us that do this bug is a real pain. We use TortoiseCVS in conjunction with WinMerge as a front end to cvs. Unfortunately the act of comparing historical revision changes on a file with WinMerge results in a checkout operation behind the scenes in a temporary directory, conseqently your cvs watch is cleared. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?23370> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ _______________________________________________ Bug-cvs mailing list Bug-cvs@... http://lists.nongnu.org/mailman/listinfo/bug-cvs
	[bug #23370] cvs watch will be wrongly cleared by cvs co by the same user by Simon Goldschmidt :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #2, bug #23370 (project cvs): it seems directly connected to this problem (posted to bug-cvs@... 2009-03-25 22:57 CET): Assume that sandbox 1 and sandbox 2 are two different directories e.g. for development and the other for testing. User A in sandbox 1: -------------------- $ cvs edit foo.txt $ cvs editors foo.txt foo.txt A Wed Mar 25 21:48:32 2009 -0000 serenity.petertoft.dk /home/A/foocvs1 User B -------------------- $ cvs update -A foo.txt $ cvs update -r 1.1 foo.txt $ cvs update -A foo.txt $ cvs editors foo.txt <as many updates as you want - no problems> foo.txt A Wed Mar 25 21:48:32 2009 -0000 serenity.petertoft.dk /home/A/foocvs1 User A in sandbox 2: -------------------- $ cvs update -r 1.1 foo.txt $ cvs update -A foo.txt $ cvs editors foo.txt ## NO LOCK on foo.txt - BUMMER - the lock should have been kept ## _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?23370> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ _______________________________________________ Bug-cvs mailing list Bug-cvs@... http://lists.nongnu.org/mailman/listinfo/bug-cvs
	[bug #23370] cvs watch will be wrongly cleared by cvs co by the same user by Simon Goldschmidt :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #3, bug #23370 (project cvs): This is severely impacting our workflow. Our group does a lot of development in graphical, model-based software tools, and those files cannot be merged easily. We rely heavily on cvs-edit commands, and the fact the the edits are being cleared is causing us lots of grief. I have attempted to create a workaround using the CVS scripting hooks, and I've got a solution that almost works, but doesn't quite make the cut. Here is an overview of what I've attempted so far. CVS stores the edit/watch info inside the repository in CVS/fileattr files for each directory in CVS. The "notify" administrative file allows programs to be run whenever a user performs cvs-edit or cvs-unedit. I was able to create a perl-script that was run via notify that created a copy of all fileattr files affected by the unedit or edit command. The fileattr files were copied into a "fileattribbackup" subdirectory of CVSROOT, which mimics the directory structure of the actual repository. The next step is to then copy the "backup" fileattr files stored in CVSROOT into the repository whenever a user performs a checkout, which can be performed by specifying the perl script to run in the "modules" file. Now, the problem I'm facing is that when my script is called from "notify", CVS has not yet modified the fileattr files, so the files that get copied into the CVSROOT backup area are basically 1-rev behind. This is my major roadblock at this point. Does anyone have better ideas of how to handle this? Another idea I was throwing around was to monitor all of the "fileattr" files for changes in a continuously running process, which would copy them to the backup location when they change. Then the checkout script could run as before. This seems like asking for trouble (at least more than the previous solution), because then I need to deal with cvs locks and such. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?23370> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ _______________________________________________ Bug-cvs mailing list Bug-cvs@... http://lists.nongnu.org/mailman/listinfo/bug-cvs
	[bug #23370] cvs watch will be wrongly cleared by cvs co by the same user by Simon Goldschmidt :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Follow-up Comment #4, bug #23370 (project cvs): I've attached a modified version of update.c, which was downloaded from the 1.11.23 sources. I've commented out 5 lines of code, which I believe are the culprit for this bug, (at least the comment directly above them indicates so).. (file #18988) _______________________________________________________ Additional Item Attachment: File name: update.c Size:86 KB _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?23370> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ _______________________________________________ Bug-cvs mailing list Bug-cvs@... http://lists.nongnu.org/mailman/listinfo/bug-cvs