Bugzilla – Full Text Bug Listing
| Summary: | Preference to Clean timestamps during a build or synchronize. | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Daniel Schneller <daniel.schneller> |
| Component: | CVS | Assignee: | platform-cvs-inbox <platform-cvs-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | AndrewBachmann, andy.w.freeman, gunnar, rlatta, sytze.van.koningsveld |
| Version: | 3.0 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Daniel Schneller
The "compare file content" option only applied to compares and merges. In the case you describe, you will want to use the Clean Timestamp menu command available in the context menu of the sync view, this will reset the timestamp for any files whose content match the content on the server. It would be nice though to have the option of making this the default behaviour. Although it may increase the time necessary for the sync itself, I would prefer the extra comfort of not having to select the menu myself each time. Is there a chance of implementing a switch for this somewhere in the configuration? Yes, it would be possible. I'm not sure if it would be best to do it after a build (since that's when the files are touched) or during a synchronize. Probably easier to do it on a sync. We could also save hitting the server if we allowed the user to specify one or more directories or files where the touching occurs and just keep the base cached somewhere locally. I don't know if this should be related or not, but when selecting multiple files in Eclipse 3.1M4, the "Clean Timestamps" option does not batch the action. It authenticates, cleans one file, resets, then repeats the action with the next file. Same for me. Apart from the time penalty you get, the CVS server may lock you out if pserver is used from inetd which believes the process to be faulting when more than a certain number of connections per minute is reached. However there are still occasions when the file compare (on double click) show no differences whatsoever and the clean timestamps function did not and does not remove them from the view. (In reply to comment #3) That would be awesome if there was an option I could check to tell Eclipse to automatically Clean Timestamps every time I sync. Any chance of adding this option? > Yes, it would be possible. I'm not sure if it would be best to do it after a > build (since that's when the files are touched) or during a synchronize. > Probably easier to do it on a sync. We could also save hitting the server if > we allowed the user to specify one or more directories or files where the > touching occurs and just keep the base cached somewhere locally. The helpwanted tag means that there is no plan to address the issue but patches will be accepted. *** Bug 92151 has been marked as a duplicate of this bug. *** *** Bug 92159 has been marked as a duplicate of this bug. *** Imagine this common and very often situation: 1. build your project with ANT (command line),i.e. new files are generated and consequently compiled 2. refresh project in Eclipse 3. try to build -> Then Eclipse: 3.1 notices, that generated files have new timestamp 3.2 copies all generated *.java to output folder (in my case more than 1000) 3.3 compiles all these files How to avoid this situation? To make a redundant and timely&memory expensive step - 'synchronise with repository' and there 'Clean Timestamp'? I would suggest to add this feature also to Navigator context menu, and after that everything what you must do after ANT build is to 1.refresh source folder 2.clean timestamps of this source folder 3.refresh output folder 4.build project (of course without redundant compiling) Seems to me what you want is an ANT task that will clean the timestamps. There is already one for refreshing so your ant task would look something like this (if I understand you correctly): - generate source - refresh workspace - clean timestamps - build In reality each of these tasks could be an ant task or a builder in Eclipse with build dependencies. I don't really have a feel for how difficult it would be to implement a Clean Timestamp ant task or a Clean Timestamp builder but it seems that either or both of those may be helpfull. *** Bug 108690 has been marked as a duplicate of this bug. *** I guess, have found some compromise solution. 1.clean *.class files in ant 2.generate source files with ant 3.refresh Eclipse and build project, thus the source codes are compiled only in Eclipse. So I had to customize my ant process, instead of Eclipse. Handicap is, that it lasts in Eclipse a bit longer, but I can live with that Synchronize now doies a clean timestamps. (In reply to comment #15) > Synchronize now doies a clean timestamps. > Thank you! In which version/build has been this solved? Tahnks In which version/build has been this solved? Thanks This was fixed in 3.2. In Eclipse 3.2, I am seeing conflicting java files in the Synchronize View, having no conflicts in content. Since the Clean Timestamps action has been removed, the conflicts stay in my view; even after performing a new Synchronize action and waiting a while. This leaves a cluttered Synchronize View and forces the user to perform "Update and Override" on each individual conflicting file with no content conflicts in order to be able to commit. The Clean Timestamps from Eclipse 3.1 used to be helpful here, and could be executed on a project, cleaning all timestamps in it in one go. I think there is something broke in the auto-clean-timestamps feature for Eclipse. 3.2. Is this a known bug or is it related to a setting in the preferences ? Clean Timestamps (and the synchronize in 3.2) only worked for outgoing changes. If you have a conflict, that means that a remote change has also occured and, by coincidence, matches the local contents. In such a case, you will need to perform an update to handle the conflict. As an example scenario for reproduction of the problem i have with auto-clean-timestamps, delete a file and then re-add it again from local history; this will end up as an outgoing change with no change in content. In Eclipse 3.1, the Clean Timestamps successfully removed this file from the Synchronize View as outgoing change. The major difference between the Update and Clean Timestamps for me, is that the last action is not destructive and can be run easily on a project folder; with Update I would be more cautious and inspect file by file. For the scenario you describe, a Synchronize in 3.2 will do the same thing that Clean Timestamp does (i.e. Synchronize now just doea a clean timestamp). |