Community
Participate
Working Groups
I hope I get this right... We use ant (command-line) to create production builds for our software. Key in this production release ant task is that the task gets the latest version of all libraries, sources, misc. build environment files etc. from the CVS repository. There is a difference in Eclipse's dirty flagging behaviour: After a production builds, local files that were previously updated from CVS using java package explorer context view, are marked as dirty in eclipse. Files that were previously updated using the synchronize view, eg. using 'override and update', are not marked as dirty. So scenario 1. java-package-explorer context menu "update" 2. command line production build has different dirty flag than scenario 1. synchronize-view update 2. command line production build However both scenarios result in the latest-greatest sources being present on the local filesystem. Checking the dirty files against the repository version does not reveal any differences in any case (shouldn't obviously') IMHO, no files should be flagged as dirty.
On an update, it is the server that indicates taht the timestamp needs to be reset. What CVS server version are you using? Override and Update actually deletes and then updates the file so it will be in-sync for sure. What happens if you perform a Clean Timestamps from the Synchronize view (in essence, a Clean Timestamps is like Team>Update but the client does the comparison instead of the server).
You're right, clean timestamps does resolve the issue, but, why is it that after external CVS update ant task, the GUI thinks they are dirty; the files are IMO exactly the same? We use ant: cvs command="-r -z9 -d :pserver:${cvs.login}:${cvs.password} @${cvs.server}:${cvs.repository} update -r ${cvs.branch}"
An update using the command line client may use timestamps that differ by 1 hour from those generated by Eclipse. This issue is tracked in bug 28903. *** This bug has been marked as a duplicate of 28903 ***
