This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 71488 - [50cat] CVS update/commit is severely broken
Summary: [50cat] CVS update/commit is severely broken
Alias: None
Product: versioncontrol
Classification: Unclassified
Component: CVS library (show other bugs)
Version: 5.x
Hardware: PC Windows XP
: P1 blocker with 2 votes (vote)
Assignee: issues@versioncontrol
: 70479 75254 75256 80041 83407 (view as bug list)
Depends on: 73181
  Show dependency tree
Reported: 2006-01-17 13:19 UTC by misterm
Modified: 2007-02-19 12:02 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

CVS log input file (16.97 KB, text/plain)
2006-02-20 20:42 UTC, misterm
CVS log output file (2.26 KB, text/plain)
2006-02-20 20:43 UTC, misterm

Note You need to log in before you can comment on or make changes to this bug.
Description misterm 2006-01-17 13:19:09 UTC
[ BUILD # : RC1 ]
[ JDK VERSION : 1.4.2_xx ]

The following critical problem just happened to me:

I modified several files and commited them. Then, my friend updated its local copy of the files and didn't see my changes. I checked the file in my copy and it wasn't marked as modified. Then I updated my copy. CVS support _lost all my changes_ in the file.
Comment 1 _ pkuzel 2006-01-17 14:11:17 UTC
Could you be more descriptive please?

What have happened, silent commit failure?
Any messages from output window or C/S protocol log (-J-DcvsClientLog)?
Comment 2 misterm 2006-01-17 14:13:33 UTC
Silent commit failure and update working as clean copy, with no reason. No 
messages were displayed in the output window. The versioning window showed no 
modified file after the commit operation.
Comment 3 Peter Pis 2006-01-17 14:20:45 UTC
Please attach cvs log, thanks. (-J-DcvsClientLog=/tmp/cvs-lib)
Comment 4 _ pkuzel 2006-01-17 15:15:16 UTC
Do you remember your "commited" files content before the like-clean-update?
(looks like Revert Modifications action was used... :-()
Comment 5 misterm 2006-01-17 15:58:54 UTC
> Please attach cvs log, thanks. (-J-DcvsClientLog=/tmp/cvs-lib)

I cannot reproduce the issue, but it seems like one that I've seen before RC1. 
I remember developers thought there was a problem with CVS/Entries.
Comment 6 misterm 2006-02-20 20:41:55 UTC
It happened again.

CVS/Entries file for the file contained:

/ Feb 20 18:13:44 

Then I ran update and it still contained:

/ Feb 20 18:13:44 

Then I added a space, removed it and saved the file. CVS/Entries remained 

Only when I diffed the file after that changes were displayed. It was not 
possible to commit the file, even by using the old NB 4.1 CVS support.
Comment 7 misterm 2006-02-20 20:42:36 UTC
Created attachment 28957 [details]
CVS log input file
Comment 8 misterm 2006-02-20 20:43:01 UTC
Created attachment 28958 [details]
CVS log output file
Comment 9 misterm 2006-02-20 20:44:49 UTC
Files attached.
Comment 10 _ pkuzel 2006-02-23 15:10:19 UTC
I see:
  - update
  - update
  - checkout

Nothing suspicious. In other words I miss commit output.
Comment 11 misterm 2006-02-23 17:34:59 UTC
Yes, it does not contain a commit, since what I did was:

1. Ran update since the file was not marked as modified, although it was 
different from CVS. Nothing happened, though.
2. Added a space, removed it and saved the file then ran update again. Then NB 
was able to detect the file has been modified.
3. I diffed the file and then it was able to show changes.
Comment 12 Peter Pis 2006-02-23 17:46:30 UTC
Btw, what is the version of cvs server?
Comment 13 Peter Pis 2006-03-02 10:29:29 UTC
Finally I have discovered one case in which this can happen. There should be
ensured that status of files will be changed only if the response of cvs server
contains information about all committed files. 
Automatic tests discovered following:
1. In NetBeans there are changed 3 files in package.
2. Commit is invoked on this package.
3. But if cvs server returns responce only for 2 of 3 files, then ALL of them
are shown as up-to-date. This is wrong. 
Comment 14 _ pkuzel 2006-03-02 15:51:28 UTC
issue #73181 relates to ppis observations.
Comment 15 _ pkuzel 2006-03-14 15:42:30 UTC
5.5_candidate, so I plan to backport issue #73181 fix that causes this issue
into release55 branch (there can be yet another unknown cause).
Comment 16 _ pkuzel 2006-03-16 10:52:21 UTC
5.5_fix: issue #73181 backported to release55 branch
Comment 17 saeder 2006-03-22 11:23:57 UTC
What about Netbeans 5.0?
That is critical!
Comment 18 _ pkuzel 2006-04-04 10:21:23 UTC
tstupka was able to reproduce even with this fix.
His scenarion is somehow connected to conflicts.

Similar applies to tzezula.

Peter could you try to find an another reprocase?
Comment 19 mclaassen 2006-04-10 16:54:04 UTC
This is super critical and I certainly hope this is fixed ASAP (like today!) 
This has bitten today and again last week.  Fortunately we caught it these times.

I guess that now that we know that CVS commits can be unreliable, we can look
here first if our test cases work and our QA builds don't.
Comment 20 _ pkuzel 2006-04-10 20:04:26 UTC
Could you provide details, please?

Did not you get "Up-to-date check failed" in commit right before the broken
commit (several reports point in this direction)? 

Did the pre-commit diff contain all changes (nobody remembered)?

Were distributed commit mails (looks like server does not distribute any mail at
all in this case)?

Any other observation?
Comment 21 mclaassen 2006-04-10 22:00:06 UTC
Unfortunately this is an error that you may not realize has occured for a long
time.  It wouldn't be so bad if the "Show Changes..." reported back that the
file was not up-to-date.  Even if a commit is suspected to have failed, there is
no way to know since the up-to-date doesn't show.

There is no information on this file in our logs (we did know about the logging
switch at the time).  However, we did get some access errors from last week
where the message was that the system could not access the file because they
were in use by another process.  

The funny thing about this particular error is that those files don't exist in
the main-line anymore.  Other branches with this file have been checked out, but
no projects using these files have been opened for weeks.  Only the main-line
project is open.

It found a few folders that don't exist and in each of those few folders, it
found a few files...not all the files and not all the folders.  These files are
not on the disk or in the CVS/Entries file either.

Comment 22 Peter Pis 2006-04-20 08:14:43 UTC
*** Issue 75256 has been marked as a duplicate of this issue. ***
Comment 23 Peter Pis 2006-04-26 08:34:30 UTC
According to no new reproducible steps -> INCOMPLETE.
Comment 24 Peter Pis 2006-04-26 10:12:00 UTC
Another observations.

1. Check out project from repository. (PC 1)
2. Check out the same project from repository. (PC 2)
3. Execute "CVS | Show Changes" action. (PC 1 and PC 2)
4. (PC 1) Modify 3 files.
5. (PC 2) Modify and save one of those 3 files modified in step 4. (The same
line to make a conflict). Commit this file.
6. (PC 1). Try to commit. Error dialog shows up. Invoke "Update" action from
"Versioning" view. Accept the remote one). (PC 1)
8. (PC 1) From "Versioning" view invoke "Commit". All files are listed in
"Commit" dialog. Push "Commit" button.

All files are committed with the exception of file that was in conflict. But
after the fix for this issue, file is still [Locally Modified](listed in
"Versioning" view and also with blue color and Annotation in explorers).
Invoking "Refresh" or "Update" action should cause that file will be up-to-date.
(Cos the work file content is identical with repository content). If user
modifies the file and commits it, no data are lost. (everything is in
repository). Maybe "Refresh" action should be performed immediatelly after
conflicts are resolved and changes are accepted.
Comment 25 Peter Pis 2006-04-27 13:27:28 UTC
*** Issue 75254 has been marked as a duplicate of this issue. ***
Comment 26 jww2nc 2006-05-10 18:46:21 UTC
From what I've read, this describes a problem we've been having in my small
development company while using Netbeans 5.0 to replace winCVS as well.  I don't
have concrete CVSLogs to prove the point, but anecdotally, this is what happens:

1.  Edit locally several files.  Compile, versioning calls them 'locally modified'.
2.  Update from CVS.  If one of the local modifications causes conflicts vs one
of the repository versions, use conflict manager to resolve.
3.  All files that were locally changed revert to 'up-to-date' rather than
'locally modified'. Diff results are useless.
4.  Only way to resolve this is to open each file locally modified, make a
trivial change (add and delete a space), and then compile.  Old changes are now
noted and status reverts to 'locally modified'.  This must be done for every
single file, and has caught us several times.  This is consistant across
multiple (3-6) users and dates.
Comment 27 Peter Pis 2006-05-10 19:42:00 UTC
To " jww2nc": Problem you have described shouldn't occur in 5.5.
Comment 28 Jesse Glick 2006-07-25 17:24:45 UTC
I have seen a bug which sounds similar to this, but might not be the same. No
idea how to reproduce. Was working on a project, did something which involved
changing a bunch of files, committed. Days later found out that one of the files
I changed had not been committed. NB CVS did not show it as modified, nor did
command-line CVS, i.e. I guess timestamp was not changed? The only way to get
CVS to commit it was to touch it.
Comment 29 phamernik 2006-08-01 20:42:46 UTC
I can see this problem approximately once a month during last half year. Commit
command always forgets some file to commit and cvs update doesn't help even if
we run it several times. NB never reports any exception AFAIK. It's not possible
to recognize this problem inside Netbeans, only by manual comparing cvs log of
each file with its local version number. 
Please try to fix this. When it happens, it always takes much time to discovery it.
Thanks. Petr.
Comment 30 Maros Sandor 2006-08-02 09:30:44 UTC
Can someone remember whether the file that was not committed:
1) may have been merged by a preceding update command?
2) was listed in versioning view as Locally Modified before commit?
3) was annotated in blue (in the explorer) before commit?
4) was listed in commit window prior to commit?
5) was listed in the commit log (output window) as having been committed?

Please provide as much detail as possible (especially your NB version), we are
trying hard to pinpoint the problem but still we are just searching for a way to
reproduce it.
Comment 31 misterm 2006-08-02 11:33:34 UTC
1) Not always
2) Yes
3) Yes
4) Yes
5) No idea

Comment 32 Maros Sandor 2006-08-02 11:44:45 UTC
misterm: your NB version? As was previously mentioned, the commit was partially
fixed in 5.5 (and trunk).
Comment 33 misterm 2006-08-02 11:50:55 UTC
Comment 34 Maros Sandor 2006-08-02 12:51:07 UTC
jglick, phamernik: have you also experienced this in 5.0?
Comment 35 phamernik 2006-08-02 12:54:20 UTC
yes, I use 5.0.
Comment 36 Jesse Glick 2006-08-02 14:19:19 UTC
So I can remember one particular case that is in CVS history. I have a feeling
there were others but I can't find them; I think this was the most recent
occasion. I always use daily dev builds so the javacvs code would have matched
time of occurrence. On June 28 2006 I made a change to a project which involved
adding several files and modifying at once. I committed as
usual - perhaps using Versioning window to see all project changes, but I am not
sure; I might have e.g. right-clicked the project and done Diff and Commit
instead. Anyway, the result was that all the added files were committed
correctly, but the modified file was not only not committed but did not show up
as modified (including to command-line cvs up, cvs diff, cvs stat). It was not
until July 13 that I noticed that the repository version of the file was
incorrect and forced this file to be committed from my working dir (by touching
it and committing from the command line). So to your questions: (1) no; (2-5)
don't remember, unfortunately.
Comment 37 Tomas Zezula 2006-08-02 16:11:37 UTC
I had the problem with commit in the 5.0.
As far as I remember it happened in the following way:
1) I updated files before commit
2) Someone changed files in the repository
3) I did commit but it failed due to conflict
4) I've updated again and fixed conflict
5) I committed files but the file which had conflict in step 3 wasn't committed.
Comment 38 Maros Sandor 2006-08-04 13:09:47 UTC
*** Issue 80041 has been marked as a duplicate of this issue. ***
Comment 39 Jesse Glick 2006-08-11 20:07:32 UTC
OK, just happened to me again. 060808 dev build. I was modifying some files in
projects/projectui. I diffed (main menu item, with project root node selected),
verified that the diff was OK, and tried to commit. Failed, saying one file was
out of date. Updated (main menu item) and committed again (main menu item). All
files except one (*not* the one that was merged) were committed.


IDE: [8/11/06 2:56 PM] Diffing "Project UI" started
IDE: [8/11/06 2:56 PM] Diffing "Project UI" finished

IDE: [8/11/06 2:57 PM] Committing "Project UI" started
cvs server: Up-to-date check failed for `'
cvs [server aborted]: correct above errors first!
IDE: [8/11/06 2:57 PM] Committing "Project UI" finished

IDE: [8/11/06 2:57 PM] Updating "Project UI" started
M src/org/netbeans/modules/project/ui/
M src/org/netbeans/modules/project/ui/
M src/org/netbeans/modules/project/ui/
RCS file:
retrieving revision 1.37
retrieving revision 1.38
Merging differences between 1.37 and 1.38 into
M src/org/netbeans/modules/project/ui/
M src/org/netbeans/modules/project/ui/
IDE: [8/11/06 2:57 PM] Updating "Project UI" finished

IDE: [8/11/06 2:58 PM] Committing "Project UI" started
Checking in;
new revision: 1.12; previous revision: 1.11
Checking in;
new revision: 1.22; previous revision: 1.21
Checking in;
new revision: 1.22; previous revision: 1.21
Checking in;
new revision: 1.39; previous revision: 1.38
IDE: [8/11/06 2:58 PM] Committing "Project UI" finished

Note that is listed as modified, yet it is not committed.

On disk, now has the correct timestamp (acc. to when it
was really edited), but CVS/Entries has

/ Aug 11 18:08:27 2006//

which is the same timestamp, not the actual mod time of rev 1.39. Therefore

nb_all$ cvs -q di projects/projectui
nb_all$ touch
nb_all$ cvs -q di projects/projectui
Index: projects/projectui/src/org/netbeans/modules/project/ui/

I did not use the Versioning view at all today. I am not sure I remember, but I
think was listed in the commit dialog on the first failed attempt to
commit but not on the second attempt.
Comment 40 Maros Sandor 2006-08-18 12:16:04 UTC
Reproducible, thanks a lot.
Comment 41 Maros Sandor 2006-08-18 14:34:38 UTC
A file that is merged during Update resets status of the previous reported file
to up-to-date.
I recommend backporting into 5.5 and 5.0 after a bit of testing.

new revision: 1.39; previous revision: 1.38
Comment 42 Maros Sandor 2006-08-23 15:30:14 UTC
Merged into release55.

new revision:; previous revision:
Comment 43 Maros Sandor 2006-08-24 16:07:05 UTC
*** Issue 83407 has been marked as a duplicate of this issue. ***
Comment 44 Maros Sandor 2006-09-01 09:42:00 UTC
*** Issue 70479 has been marked as a duplicate of this issue. ***
Comment 45 pgebauer 2006-09-25 10:40:54 UTC
The fix has been backported into release50_fixes branch.

Checking in;
new revision:; previous revision: 1.36