bugConcurrent Versions System - Bugs: bug #21023, Possible commit problem

 
 

bug #21023: Possible commit problem

Submitter:  None
Submitted:  Mon 10 Sep 2007 11:23:09 PM UTC
   
 
Category:  Bug Report Severity:  3 - Normal
Item Group:  None Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Release: 
Fixed Release:  None Fixed Feature Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 08 May 2008 07:56:13 PM UTC, comment #3: 

Doesn't seem to be a source code issue.  More like a user issue.  Closeable.

Eugen Zglimbea <eugenzglimbea>
Fri 14 Sep 2007 11:18:39 PM UTC, comment #2: 

Re comment #1
There are other problems with having an editor open with a CVS controlled file than just this window of oportunity for the date to get funky.
The biggest I know of is that if the user happens to change the editor buffer after issuing the `cvs commit` (or gui equivalent), and then saves the result, the user will loose any changes that may have been merged in by CVS from other users checking in, i.e., when CVS is used in it's CONCURRENT mode of operation.

The ONLY sane things to do are:
1) educate the users that they will at some point cause one another (not just themselves) to loose changes that others put into CVS, and the other coder may not be happy about it & the boss will NOT be happy about it.  (the loss can be fixed with a `cvs -jr1 -jr2` where r1=r2 - 1rev  and r2=rev before loss, but don't tell them that).
2) make it company/group/project policy to discipline (publicly if necessary) anyone who has an editor open while running CVS commands.

Summary: the problem you see is only the very tip of the iceberg created by having a CVS controled file open in an editor while also running a CVS commit OR update command.  I doubt I am alone in seeing this as a user education problem, but I am going to leave the bug open.
Advice: DO NOT ALLOW THE PRACTICE TO CONTINUE.



Todd Denniston <tdennist>
Fri 14 Sep 2007 08:35:32 PM UTC, comment #1: 

This is considered to be somewhat of a problem at our shop as we have had two or three instances now where users have thought they were implementing a change and weren't.  Granted we have tried to tell them not to modify their code until they are sure that the commit has completed, but you know how users are....

John Elgin

John C. Elgin <johnelgin>
Mon 10 Sep 2007 11:23:09 PM UTC, original submission:  

At our work we use the pserver access method to interact with the CVS repository.  We had an instance where a user had issued a commit and prior to the commit completing they made a last minute change to the file.  A subsequent “cvs status” showed the file to be up to date so the user concluded that their change was included in the repository revision; however, that was not the case.

While tracing the client we found, shall I call it a “window of opportunity”, which we believe was the possible cause of the incorrect situation.  To illustrate this, let’s take the following scenario:

1) User issues commit
2) send_modified in client.c sends the file --- (file has a timestamp of yesterday)
3) Prior to the commit completing (possibly due to a repository lock on the server) the file is modified in the client’s work area by another process (file now has a timestamp of today).
4) The server then talks back and the client gets a “Checked-in” response
5) The client then eventually calls update_entries who reads the new revision from the server and gets the files timestamp (todays) for the file in the work area and copies that to local_timestamp.
6) Register is then called passing local_timestamp (todays – not yesterdays).
7) Register creates a new entnode with todays (incorrect) timestamp and eventually returns to update_entries.
8) update_entries returns to call_in_directory who then calls Entries_Close to write out the entries file.

The CVS/Entries file now has the revision that matches what is in the repository; however, the entries timestamp does not reflect the files timestamp that existed for the file when it was actually committed.  Consequently, a status, diff, etc will say that the file is up to date.

Let me state also that we are back-leveled a bit (1.11.14).  Can someone please let me know if this doesn’t seem to be a problem in the current 1.11 branch?  Also, if it is a problem in the current 1.11 branch then please let me know that also.  I can be reached at either of the email addresses below.

Thanks for your assistance,
John Elgin     
-email is unavailable-
-email is unavailable-

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dprice (Updated the item)
  • -email is unavailable- added by eugenzglimbea (Posted a comment)
  • -email is unavailable- added by johnelgin (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-05-08 dprice StatusNone Invalid
        Open/ClosedOpen Closed
    2007-09-14 tdennist Carbon-CopyRemoved 45305 -

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code