Community
Participate
Working Groups
FWIW, I figured this would have been asked/reported already, but couldn't find any dups by searching. When you export via Archive File, the timestamp of all the files in the archive is set to the current time, regardless of the local timestamp on disk. Likewise, importing back from the archive via Existing Projects into Workspace sets the timestamp of all files to the time of import. There's nothing broken by this behaviour, but it is annoying from a development perspective. If someone sends me a zip of their projects, everything is "new" and there is no quick or easy way to tell what has been recently changed. If you use zip files as a way to exchange information, you really need a binary comparison tool in addition to Eclipse. Is there any reason for this behaviour? If not, please preserve timestamps on export, and preferably import too. If there is a reason to keep the current behaviour, this could be provided as an optional setting in the wizard.
Created attachment 124648 [details] Patch v01 While importing the timestamp is not been set. Same for exporting a zip file as well. Fix is in the patch attached. During the Tar File import the timestamp is not read at all. I'll raise a separate bug (Bug# 263598) for that.
*** Bug 180348 has been marked as a duplicate of this bug. ***
Patch v01 released to HEAD
Prakash, I think the target milestone is wrong (should be 3.6m3). I fully agree with Tim that this is important functionality. I have two more very concrete use-cases: (1) Importing a project that includes CVS/ or .svn/ version control information. On import, the project is automatically associated with the original Repository (which is nice!), but all files appear to be modified (because the timestamps have not been preserved). (2) Importing a project that includes some build output. On import, everything will be rebuilt unnecessarily even if all the project used to be up-to-date. This may be particularly problematic with C/C++ projects. Would it be possible to get a backport of this to 3.5.2 ? I'd stronlgy like to have this in our product based on 3.5.x.
Fixing the target milestone (3.5m3 was definitely wrong, 3.6m3 is correct as per CVS). Bug 293235 has already been opened for tracking the backport of this fix to Eclipse 3.5.2.
