[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #21023] Possible commit problem
From: |
anonymous |
Subject: |
[bug #21023] Possible commit problem |
Date: |
Mon, 10 Sep 2007 23:23:10 +0000 |
User-agent: |
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727) |
URL:
<http://savannah.nongnu.org/bugs/?21023>
Summary: Possible commit problem
Project: Concurrent Versions System
Submitted by: None
Submitted on: Monday 09/10/2007 at 23:23 UTC
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:
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
John@JCElgin.com
John.Elgin@eds.com
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?21023>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
- [bug #21023] Possible commit problem,
anonymous <=