Community
Participate
Working Groups
[build 200404240010]. There are some (bizarre?) inconsistencies caused when working in a mixed environment with Eclipse CVS and command line CVS. Eclipse is negatively affected, though command line CVS is not. My environment is: 1. A Windows XP workstation with Eclipse. 2. A Unix-based server for home directories and development space. 3. A Unix-based command line CVS on the development server. My workspace is in 'U:/Workspace' (my Unix home directory). For CVS operations, if I use Eclipse with this workspace _exclusively_ I don't have problems. If I go command-line _exclusively_ I don't have problems. Eclipse is perfectly happy working on the U:/Workspace drive, editing the code, compiling, you name it. But Eclipse's CVS gets confused if I use command line CVS commands. For example: 1. Check out the project using Eclipse. Works great. 2. Open up a shell and manually edit a file using Emacs. Works great. Eclipse sees the change. 3. If I use Eclipse CVS to commit the changes, no problem. 4. HOWEVER, if I do a 'cvs commit' at the command line, the file is committed and shortly thereafter... Eclipse goes all the heck. Specifically what happens, I can't tell you -- but what I see is a "large portion" of the files in my project are suddenly marked as outgoing changes. If I do a comparison, there are (of course) no actual changes in the files. Nevertheless, Eclipse becomes convinced that many/most of the files the project have changed, and wants to commit them. I've noticed a few other incidents that cause loss of synchronicity between the CVS store and the project. Clearly it has something to do with the command line CVS touching files or making changes to the local project in ways Eclipse doesn't expect. Another way to trigger the problem: 1. Do a 'cvs status' on the entire project (command line). This has the same effect as above (eg., checking in a file by command line). Curiously enough, there is nothing I can do in Eclipse that will confuse the command line CVS. I can work on files, synchronize, run CVS status and logs, commit or update anything I want. Command line CVS is always doing the right thing. It doesn't care if I use Eclipse or command line Emacs to edit files, and it never gets out of sync. Also, I haven't been able to figure out the pattern of exactly which files are affected or why. At first I thought it was only files subject to .cvsignore, but that's not correct. In my last experiment, I see files that should be subject to .cvsignore showing up in the sync view, and I also see some files that are currently in CVS showing up. RESOLUTION If this happens to you: 1. Commit your changes (if any) using _command line_ CVS, as it won't be confused. 2. In Eclipse, after you have commited your changes by command line, right-click on your project and choose to Override and Update. This will effectively grab the latest file from CVS, overwriting all your local files. WORKAROUNDS 1. Only use command line CVS. or 2. Only use Eclipse CVS.
I suspect the problem you are seeing is due to a difference in how CVS command line on windows and Java on windows determine file timestamps (usually involving a FAT or network drive). When you perform a commit using the command line client, my guess is that the command line client changes the timestamp either on the files or in the CVS/Entries file. Also, it turns out that for some drives, CVS command line uses a different method for determining the timestamp then Java so the timestamps from Java often differ by 1 hour. If you don't mind, could you have a look at the timstamps on the files and in the CVS/Entries file before and after committing using both CVS command line and Eclipse and add what you find to this bug report.
I did a few timestamp experiments. First, I should point out that after reading your comment, I checked the clocks on both systems and found a 6 second disparity. That has been corrected and they are now in sync with each other, at least reasonably so (within 1 second I would say). To start, I'm working with the DocumentTest.java file. Everything is in a good state, Eclipse CVS is happy; here's the file, and the CVS/ directory files: -rwxr--r-- 1 zbeckman users 9.0K Apr 29 00:42 DocumentTest.java -rwxr--r-- 1 zbeckman users 300 Apr 29 01:30 Entries -rwxr--r-- 1 zbeckman users 61 Apr 24 01:01 Repository -rwxr--r-- 1 zbeckman users 57 Apr 24 01:01 Root Now, I'll do a CVS status from the command line, and as you can see CVS command line has touched the Entries file: -rw-r--r-- 1 zbeckman users 302 Apr 29 09:05 Entries Note that it removed the execute flag (it's not an executable file, I don't know why Windows keeps adding that flag) and it adjusted the time. The local time, by the way, is 9:05. So far, no major problems. Now I'll do a command line commit: -rw-r--r-- 1 zbeckman users 9.0K Apr 29 09:07 DocumentTest.java -rw-r--r-- 1 zbeckman users 302 Apr 29 09:07 Entries -rwxr--r-- 1 zbeckman users 61 Apr 24 01:01 Repository -rwxr--r-- 1 zbeckman users 57 Apr 24 01:01 Root Again, only DocumentTest.java and Entries has been touched. Eclipse looses sync and complains about my having to do a refresh. I do. Then I do a Team Sync. Still no problems. So, I'm going to move to the top-level of the project and do a full cvs status. In the past, this usually causes major problems. Still no problems. Starting to think that the synchronization of the clocks may have solved the problem, but I'll try a few more things. So, in the root of the project, I modify build.xml and commit it, all from the command line. In Eclipse I do a Team Sync and... get an odd result. It shows the build.xml is an incoming change. Most likely I need to refresh to get around this, so I'll refresh. And YIKES, all of a sudden half the project is marked as an outgoing change. There doesn't seem to be a pattern to it either. I've got a lot of .cvsignore files, some .jar files that haven't been touched in a long time, a little bit of our source code -- but not much of it, strangely enough. It seems that recently worked on code is not marked outgoing, at least this time... Here are some statistics on some of the files that have been flagged as outgoing changes, but should not have been: BEFORE doing anything: -rwxr--r-- 1 zbeckman users 628 Feb 14 12:09 ComponentBorder.jwc -rwxr--r-- 1 zbeckman users 4.0K Apr 29 09:20 Entries -rwxr--r-- 1 zbeckman users 24 Apr 9 15:03 Repository -rwxr--r-- 1 zbeckman users 57 Apr 9 15:03 Root AFTER doing a command line status and commit: -rwxr--r-- 1 zbeckman users 628 Feb 14 12:09 ComponentBorder.jwc -rw-r--r-- 1 zbeckman users 4.0K Apr 29 09:24 Entries -rwxr--r-- 1 zbeckman users 24 Apr 9 15:03 Repository -rwxr--r-- 1 zbeckman users 57 Apr 9 15:03 Root AFTER doing an Eclipse 'refresh' and 'Team Sync:' -rwxr--r-- 1 zbeckman users 628 Feb 14 12:09 ComponentBorder.jwc -rw-r--r-- 1 zbeckman users 4.0K Apr 29 09:24 Entries -rwxr--r-- 1 zbeckman users 24 Apr 9 15:03 Repository -rwxr--r-- 1 zbeckman users 57 Apr 9 15:03 Root AFTER doing a 'Override and Update' in Eclipse, trying to get things "back to normal:" -rwxr--r-- 1 zbeckman users 628 Feb 14 12:09 ComponentBorder.jwc -rwxr--r-- 1 zbeckman users 4.0K Apr 29 09:30 Entries -rwxr--r-- 1 zbeckman users 24 Apr 9 15:03 Repository -rwxr--r-- 1 zbeckman users 57 Apr 9 15:03 Root After all this -- specifically, after doing the Overide and Update command -- I expect things to be back in good order. One strange exception: One directory, assets/ which is full of images and whatnot, is marked as an _incoming_ change. That can't be right. They are all version 1.1 and they are all present in my assets/ directory. Thinking this is a Team Sync view bug, and not an actual reflection of what's going on, I quite Eclipse and start it up again. Yep, that was it -- now everything is in good standing. So, it looks like command line and Eclipse CVS just don't like each other. Sure would be wonderful if this could be fixed. In the meantime, I'm adding this to my project directory on the server: % alias cvs="echo Don't use command line CVS in an Eclipse project!"
What CVS command line client are you using? In your "AFTER doing a command line status and commit" step, the Entries file changes but no other file timestamps change. I suspect that the CLI you are using is trying to be smart and adjust the timestamps to make the files in-sync. Unfortunately, it probably has a different method of determing the entry line contents. It would be interesting to see what modifications were done. If it's not too much trouble, could you attach the contents of the Entries file before and after the command line status and commit? P.S. We've just released a command name Update Clean (until a better name is found) that will adjust the timestamps back to what Eclipse expects.
CVS version info (standard cvs distro): tonatiuh:zbeckman% rpm -qf /usr/bin/cvs cvs-1.11.2-17 tonatiuh:zbeckman% cvs --version Concurrent Versions System (CVS) 1.11.2 (client/server) Copyright (c) 1989-2001 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors CVS may be copied only under the terms of the GNU General Public License, a copy of which can be found with the CVS distribution kit. Specify the --help option for further information about CVS tonatiuh:zbeckman% I'll try to get you the more detailed diagnostics on the Entries file shortly.
Waiting for info from reporter
I ran a CVS status on one directory (WEB-INF/). The results of a diff between the Entries file before the update (e1) and the file after the update (Entries) are: tonatiuh:zbeckman% diff CVS/Entries /tmp/e1 42a43 > /ComponentBorder.jwc/1.2/Sat Feb 14 19:09:06 2004// 57a59 > /ImportSchema.html/1.1/Mon Mar 29 23:57:10 2004// 58a61 > /JuvenileInformation.html/1.2/Sat Feb 14 02:14:56 2004// 60a64 > /MainBorder.jwc/1.1/Fri Feb 13 20:33:37 2004// 89a94 > /PicklistSelect.html/1.1/Fri Feb 20 18:54:21 2004// 101,106d105 < /ComponentBorder.jwc/1.2/Sat Feb 14 20:09:06 2004// < /ImportSchema.html/1.1/Tue Mar 30 00:57:10 2004// < /JuvenileInformation.html/1.2/Sat Feb 14 03:14:56 2004// < /MainBorder.jwc/1.1/Fri Feb 13 21:33:37 2004// < /PicklistSelect.html/1.1/Fri Feb 20 19:54:21 2004// < D It appears that a small subset of the files (five out of about 50) have had a one hour adjustment made to their timestamps. I don't know why it would be these 5, as I mentioned above the problem seems to occur unpredictably (but consistently) across the file set).
Yes, that is what I expected. This is due to a difference between how Java and how CVS commad line clients determine the timestamp for files. We have provided an operation in the synchronize view called Clean Timestamps which will reset the timestamps so that the files do not appear as outgoing changes in Eclipse. That is all we intend to do.
Not wanting to be a pain, but... doesn't it make sense to track the standard CVS functionality? I mean, I'm using the authoritative, original CVS. If you don't track its functionality, don't you expect to run into problems...? It makes it impossible for us to use Eclipse CVS. We have a mixed environment, automated build scripts, etc., etc. Most of it runs on Unix. So that limits me to using a purely Unix-based command line CVS environment, which is a shame.
We do not run into problems because we rarely, if ever, use the command line client. I would be curious to know why you need to use it. If there is a shortcoming in the Eclipse CVS client that requires you to fall back to the CVS command line client, perhaps you should open up a feature request to have that addressed. As for this bug, I'm happy to leave it open but there is little chance that it will be addressed (unless you want to provide a patch;-). As I said, few Eclipse users are affected by this because they never use an external command line client or, if they do, it is not on a FAT drive or a Network drive on Windows (the only failure cases I know of).
I second the request for fixing this bug. We (must) use ant targets for cvs checkout, since we have to exclude some files and directories from the cvs modules during checkout. Ant supports this, Eclipse can only checkout the complete cvs module. The problem isn't restricted to FAT and network drives, I use NTFS and have these CVS problems, too.
Re Commet 10: Workaround is to perform a Clean Timestamps in the sync view after the checkout and you wil be fine. Also, have you looked into defining a module in the CVSROOT/modules file to meet your needs?
The problem is definitely not limited to Windows FAT file systems. The issue we run into is that our native work environment is Unix-based. I have a Unix home directory, and that directory is mounted (either NTFS or SMB) on my Windows workstation. So the problem I run into is that my file system is Unix-based, but my part-time work environment is Windows (using my Unix home directory as a workspace). This is a problem because our project is large, and Eclipse does not serve as a comprehensive development tool. For example, we use emacs, various Unix tools and ER/Studio to develop the SQL database schema, stored procedures, database build scripts, etc. -- but, these are all part of the CVS project (as are other non-Eclipse components of the project). What tends to happen is that I am working on the Unix workstation (on another system or via telnet) and make changes to the project. But if I commit those changes command line, we get a mess. I absolutely must remember to never, never, never run a CVS command via the command line, otherwise the project gets completely confused and it takes hours to figure out which files are actually changes, fix it up, and get back on good footing. Also, our ant build script is highly automated -- to the point that it can actually modify the project structure. The integration server goes even further, automatically checking out CVS source updates. So, clearly, the project has a tendency to get "out of sync" with Eclipse. This is further exacerbated because the project is a Unix-based application server. Our interaction, testing, deployment, configuration... it's all done on the Unix command line. This can't be done on a purely Windows environment. My only workaround, and it's a nasty one: I have two project directories. One is for my command-line work, where I try to focus any various Unix-side changes (for example, SQL scripts). One is for use with Windows. I have to be careful not to confuse them. I have to commit changes from one to see them in the other, which is not natural. It's very inconvenient, and once in a while I forget which directory I'm in and do a "cvs status," at which point the file stamps get whacked and I kick myself for a while... (while muttering incoherently about Eclipse's CVS module...) I don't have the "clean timestamps" function yet. I don't know what that will do to my CVS repository -- perhaps it will improve the situation. Looking forward to trying it -- but my concern is, will that have a negative effect on the Unix-side CVS client? Because if so, it doesn't solve the overall problem.
Re #11: Clean timestamps (which will be available from milestone 9, I presume?) might be a workaround, but since the project contains lots of files and needs to be updated (with ant) regulary, which itself takes lots of time, the need to fix all files with eclipse each time is not very tempting. I don't know what exactly can performed with cvsroot/modules regarding my problem, but since the same module needs to be checked out differently for several projects and not all users use Eclipse (but all have to use ant), it's not feasible to manage cvs checkout exclusions in a second location besides the ant buildfile.
We already have a bug for this. Marking as a duplicate. Also, I don't believe this bug makes Eclipse unusable. It does, however, adversly effect some of the advanced Eclipse CVS functionality. To be specific, the CVS decorators and the synchronize view will be showing phantom outgoing changes. As I said before, the Clean Timestamps should help here. If it is not adequate, then turning off the CVS decorators and using Team>Update and Team>Commit (the basic CVS workflows) should work fine (in the same way that the command line works fine when its use is mixed with Eclipse). As for the CVSROOT/modules file, this is a CVS mechanism for doing what you are using ant for. It allows for the configuration of logical projects (modules) from the physical modules in the repository and also supports file exclusions. *** This bug has been marked as a duplicate of 15133 ***
