1

Note: This is not about ignoring files or removing them from version control. All files in the project should stay controlled.

Some files are supposed to be changed by individual developers to fit their environment. So while they are in the VCS, I would like eclipse to ignore outgoing changes for them and stop displaying the asterisk/snowflake icon in the bottom left corner of the packages and projects above the files.

Is there a way of finetuning eclipse or the VCS plugin like that?

I am using subclipse and mercurialEclipse.

Thank you

kostja
  • 60,521
  • 48
  • 179
  • 224
  • 1
    That would be useful, but I don't know of a way to get ANY Subversion client to do that. You can use a pre-commit hook to at least warn people at commit-time that they might want to NOT commit changes to a given file, but that doesn't help with the visual indicators. – Rodney Gitzel Apr 18 '11 at 21:27
  • @Rodney Gitzel I supposed that that would be difficult at best...And keep wondering why, as this seems to be such a common pain that visual feedback sometimes confuses people into taking a unnecessary second look at the project, or assume that the indicated change is only for "those" files and don't take a second look where it would be actually advisable – kostja Apr 19 '11 at 05:32
  • @kostja It's only a pain if you're misusing the tool, which you are. There are ways to use version control that avoid having to ignore changes in versioned files. Ulidtko's answer is a good one. – Isaac Truett Apr 19 '11 at 11:37
  • @Isaac Truett It would be nice to avoid versioning for some files but I still see the possibility to disable outgoing changes as a useful feature when it could not be avoided or is a deliberate decision like distributing templates, where there are few sources and many consumers. What is your rationale behind considering it a misuse? – kostja Apr 19 '11 at 12:05
  • @kostja Making a deliberate decision to do something that is not supported by a tool and violates the industry accepted best practices for using that tool sounds like misuse to me. what other rationale do you want? – Isaac Truett Apr 19 '11 at 12:24
  • @Isaac Truett exactly, the rationale I would like to have explained is the one behind not implementing such a feature in a CVS tool and having best practices apparently disallowing it. Was it a deliberate decision and how was it motivated? The links provided by ulidtko rather explain how to work around this missing feature, not why it is missing... – kostja Apr 19 '11 at 13:11
  • @kostja It isn't implemented because it isn't necessary. There are better options for arranging your project configuration in the repository that don't require selectively ignoring outgoing changes. The feature you're asking for is just an invitation for non-obvious problems with a developer's working code set, like CVS sticky tags were. – Isaac Truett Apr 19 '11 at 15:24
  • @Isaac Truett Thank you for your time, I guess I still have much to learn about VCS theory. I have done some (2 pages of google results - not much, but...) research on CVS' sticky tags issues but was unable to found anything valuable...I also seem to lack the experience to imagine the potential problems of such a feature. Maybe you could provide some? – kostja Apr 20 '11 at 15:13
  • @Kostja http://www.inf.ed.ac.uk/systems/web/publish/cvs-revert.html has a description of how applying a sticky tag prevents you from committing changes or updating until you explicitly remove the tag. In many cases I have seen this is not obvious, especially to developers who are new to CVS. CVS tools in use at the time didn't do everything they could to highlight the problem and make it easier to fix. – Isaac Truett Apr 21 '11 at 12:12

1 Answers1

3

The common solution to this is to create versioned config template, which includes via some means local configs ignored by VCS.

See How to version control config files pragmatically?, Committing Machine Specific Configuration Files etc.

This solution could be problematic if Eclipse configuration files didn't support includeing other files, as seemingly is the case.

Community
  • 1
  • 1
ulidtko
  • 14,740
  • 10
  • 56
  • 88
  • thank you ulidtko. This is surely advisable but not always possible as some of the files in question are .classpath files, files in the eclispe .settings folders, persistence.xml and so on. And additionally, incoming changes are explicitly allowed to take place – kostja Apr 18 '11 at 16:54
  • I would like to accept your answer but I miss a direct reference to the question. Could you please add something in the lines of "Eclipse, SVN and mercurial do not support this feature"? I don't have the privilege to edit answers yet – kostja Apr 20 '11 at 15:17