Community
Participate
Working Groups
As mentioned in several other bug reports, we have also problems if we want to use eclipse's CVS support in coexistence with the 'official' cvs commandline client (we assume, there a lots of people out there, developing their software in a similar way). Eclipse: Version: 3.1.0 Build id: I20050527-1300 CDT: 3.0.0 CVS: Concurrent Versions System (CVS) 1.11.17 (client/server) So here is the way to the problem: 1. check out a project with commandline cvs client 2. create an eclipse project around it 3. ... most of the files are marked 'dirty' 4. perform a "Team->Update" in Eclipse After performing 4) most of the dirty files are marked as clean, BUT a few of them still remain dirty (why!?). In Eclipse it's not possible to get them clean, except with "Replace with -> Latest from HEAD". BUT if I do so, then eclipse set's watch/edit (if activated) on those files ("why!?" again). Note: "Clean Timestamps" in the Syncronize View doesn't work in this case. #1 We would be satisfied if a simple "Team->Update" cleanes the files. If we use "Replace with -> Latest from HEAD" as workaround, we run into problems with lots of files marked as edited by someone. #2 There seems to be another bug in this context: The Files, which get watched/edited by "Replace with -> Latest from HEAD" cannot be unedited ("Team->Unedit") within eclipse. We did some digging in the CVS/Entries file concerning problem #1: File 1: 1. after "cvs up -A" on commandline /art1.xls/1.3/Thu Mar 22 18:04:27 2001/-kb/ 2. after "Team-Update" in eclipse (clean now) /art1.xls/1.3/Thu Mar 22 17:04:26 2001/-kb/ File 2: 1. after "cvs up -A" on commandline /kommort1x.csv/1.1/Thu Mar 22 17:04:29 2001// 2. after "Team-Update" in eclipse (still dirty) /kommort1x.csv/1.1/Thu Mar 22 17:04:29 2001// 3. after "Replace with -> Latest from HEAD" in eclipse (clean now) /kommort1x.csv/1.1/Thu Mar 22 17:04:28 2001// Beside the problem with timezone (hours) there seem to be a problem with seconds. Note: In our project always the same few files affected by this phenomenon... We can't figure out, why File1 gets clean after "Team->Update" but File2 doesn't.
The root of the problem is that, on some file systems (e.g. FAT), Java uses a different means of determining a file's timestamp. *** This bug has been marked as a duplicate of 15133 ***
