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

 
 

bug #21023: Possible commit problem

Submitted by:  None
Submitted on:  Mon 10 Sep 2007 11:23:09 PM UTC  
 
Category: Bug ReportSeverity: 3 - Normal
Item Group: NoneStatus: Invalid
Privacy: PublicAssigned to: None
Open/Closed: ClosedRelease: 
Fixed Release: NoneFixed Feature Release: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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
-unavailable-
-unavailable-

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 08 May 2008 08:04:28 PM UTCdpriceStatusNone=>Invalid
      Open/ClosedOpen=>Closed
    Fri 14 Sep 2007 11:21:00 PM UTCtdennistCarbon-CopyRemoved 45305=>-

    Back to the top


    Powered by Savane 3.1-cleanup1