Community
Participate
Working Groups
Build Identifier: 20110301-1815 Changes to the org.maven.ide.eclipse.prefs file include a timestamp update on each change. We frequently toggle workspace resolution mode, which causes a timestamp update which creates a red-herring SCM change (nothing has changed except for the timestamp). For us, the timestamp is not necessary and is more of a hindrance than a help. Would you consider eliminating it? If not, perhaps a configuration option can be added to ignore the timestamp and not perform an update? Reproducible: Always Steps to Reproduce: 1.Create a new maven project 2.Note the timestamp in .settings/org.maven.ide.eclipse.prefs 3.Change the maven config 4.Note the new timestsamp in .settings/org.maven.ide.eclipse.prefs
m2e does not directly manage .prefs file, so moving to platform for consideration.
Moving to Core Runtime.
Just to be clear, you are asking that when the contents of a file changes that the timestamp of the file doesn't change?
I think he's referring to the timestamp text written inside the preference properties file on the first line. If so, I'm wondering why we are writing the file at all if it hasn't changed. Is it a case of a preference that is changed, and then reverted back to its original state?
I've downloaded Eclipse and installed m2e and am following your instructions but I don't know what "Change the maven config" means. Are there particular settings in the preferences that I need to change?
(In reply to comment #5) > I've downloaded Eclipse and installed m2e and am following your instructions > but I don't know what "Change the maven config" means. Are there particular > settings in the preferences that I need to change? I am not the original reporter of this bug, but I believe the scenario includes changing a project preference and then changing it back to its original value. This can be reproduced using any project property, for example test file enconding or a folder -- each time the property changes value the timestamp at the top of .prefs file gets updated. The makes the file "dirty" from scm point of view even if the actual property value is the same as in the source code repository and the timestamp is the only change in the file.
If what you describe is indeed the original user's scenario, then that is beyond the scope of the Eclipse preference mechanism. That process describes changing the file contents twice. Changes to the preferences file (which really means changes to the resource model) mark the file dirty because it is being compared to the previous local version. I believe this request is asking that the current team provider only mark a file dirty if the contents differ from the version that was originally checked out from the repository, rather than the previous version on the local disk. Moving to the Platform/Team team for comment. If there is a problem where the preference file is being written out but the contents really haven't changed, please describe the steps required to reproduce the problem and move the bug back to Equinox. Thanks.
(In reply to comment #7) > If what you describe is indeed the original user's scenario, then that is > beyond the scope of the Eclipse preference mechanism. That process describes > changing the file contents twice. Changes to the preferences file (which really > means changes to the resource model) mark the file dirty because it is being > compared to the previous local version. > > I believe this request is asking that the current team provider only mark a > file dirty if the contents differ from the version that was originally checked > out from the repository, rather than the previous version on the local disk. > > Moving to the Platform/Team team for comment. If there is a problem where the > preference file is being written out but the contents really haven't changed, > please describe the steps required to reproduce the problem and move the bug > back to Equinox. Thanks. DJ, the problem is the timestamp in .prefs file (see example below). Modern team providers, like GIT, already use file contents to determine file dirty/clean state and would provide desired behaviour if the timestamp did not change on each preference change. <org.eclipse.core.resources.prefs> #Thu Aug 18 08:15:06 MSD 2011 eclipse.preferences.version=1 encoding/.settings=US-ASCII </org.eclipse.core.resources.prefs>
Ah, ok that makes sense. Thanks for the clarification. Currently we use java.util.Properties objects to read/write. I'll investigate whether or not the date and timestamp can be removed from the file.
Ok, I wrote the code to strip off the timestamp before persisting the data to disk. While I was at it, I also moved the sorting code up in the hierarchy so now all preference files (not just the project prefs) are sorted. http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=1376516f931a3ca6ad0ef3caa3591418ab8a09c0 http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=f55d9b84a2dd5b83f70d2a873109383d5f6b6a47
*** Bug 361099 has been marked as a duplicate of this bug. ***
Noticed the target milestone is Juno and wondering (hoping) if there is any chance this could be fixed on Indigo? All of our projects are marked as 'changed' by version control when we check them out because the timestamp has changed in the prefs file. This makes ensuring everything has been checked in a real pain. Having to live with this problem for the next year is quite a depressing thought!
(In reply to comment #12) > Noticed the target milestone is Juno and wondering (hoping) if there is any > chance this could be fixed on Indigo? I've opened Bug 363836 to track release into the maintenance stream.
