The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex
You do want to keep in version control any portable setting files,
ReplyDeletemeaning:
Any file which has no absolute path in it.
That includes:
.project,
.classpath (if no absolute path used, which is possible with the use of IDE variables, or user environment variables)
IDE settings (which is where i disagree strongly with the 'accepted' answer). Those settings often includes static code analysis rules which are vitally important to enforce consistently for any user loading this project into his/her workspace.
IDE specific settings recommandations must be written in a big README file (and versionned as well of course).
Rule of thumb for me:
You must be able to load a project into a workspace and have in it everything you need to properly set it up in your IDE and get going in minutes.
No additional documentation, wiki pages to read or what not.
Load it up, set it up, go.
.project and .classpath files yes. We do not however keep our IDE settings in version control. There are some plugins that do not do a good job of persisting settings and we found that some settings were not very portable from one dev machine to the next. So, we instead have a Wiki page that highlights the steps required for a developer to setup their IDE.
ReplyDeleteThese are what I consider to be generated files, and as such I never place them under version control. They can be different from machine to machine and developer to developer, for instance when people have different Eclipse plugins installed.
ReplyDeleteInstead, I use a build tool (Maven) that can generate initial versions of these files when you make a new checkout.
No, I'm a heavy Maven user and use the Q for Eclipse plugin that creates and keeps .project and .classpath updated. For other things such as settings for plugins I usually mantain a README or Wiki-page about that.
ReplyDeleteAlso those I've worked with that prefer other IDEs just use the Maven-plugins to generate the files needed to keep their IDE (and themselves) happy.
This is all opinion, I suppose - but best practices over the years indicate that files specific to a given IDE shouldn't be stored in source control, unless your entire organization is standardized on one IDE and you never have any intent on switching.
ReplyDeleteEither way, you definitely don't want user settings stored - and .project can contain settings that are really developer specific.
I recommend using something like Maven or Ant as a standardized build system. Any developer can get a classpath configured in their IDE in a few seconds.
I am torn between two options here.
ReplyDeleteOn one hand, I think that everyone should be free to use the set of developemnt tools they are most productive with, as long as all source artifacts are stored in version control, and the build script (say ANT or Maven) ensures standards compliance by specifying exactly which JDK to use, which versions of which third party libraries to depend upon, running style checks (e.g. checkstyle) and running unit tests etc.
On the other hand, I think so many people use the same tools (e.g. Eclipse) and often it is much better to have some things standardised at design time instead of build time - for example Checkstyle is far more useful as an Eclipse plugin than as an ANT or Maven task - that it is better to standardise on the set of development tools and a common set of plugins.
I worked on a project where everyone used exactly the same JDK, same version of Maven, the same version of Eclipse, the same set of Eclipse plugins and the same configuration files (e.g. Checkstyle profiles, code formatter rules etc.). All of these were kept in source control - .project, .classpath and everything in the .settings folder. It made life really easy during the initial phases of the project when people were continually tweaking the dependencies or the build process. It also helped immensely when adding new starters to the project.
On balance, I think that if there are not too many chances of a religious war, you should standardise on the basic set of develop tools and plugins and ensure version compliance in your build scripts (for example by explicitly specifying the Java version).I don't think that there is much benefit to storing the JDK and the Eclipse installation in source control. Everything else that is not a derived artifact - including your project files, configuration and plugin preferences (particularly code formatter and style rules) - should go into source control.
P.S. If you use Maven, there is an argument for saying that the .project and .classpath files are derived artifacts. This is only true if you generate them every time you do a build, and if you have never had to tweak them by hand (or inadvertently changed them by changing some preferences) after generating them from the POM
No, because I only version control files that are needed to build the software. Besides, individual developers may have their own project-specific settings.
ReplyDeleteYes, except for the .settings folder. Committing the other files works well for us. There is a similar question here.
ReplyDeleteAlthough I generally agree on the "do not version generated files" approach, we have problems with it and have to switch back.
ReplyDeleteNote: I am also interested in VonC's answer, particularly about the "get Eclipse up within minutes" point. But it is not decisive to us.
Our context is Eclipse+Maven, using m2eclipse plug-in. We have a common development environment, with common directories as much as possible. But it happens sometimes that someone would try a plug-in, or change little things in the configuration, or import a second workspace for a different branch...
Our problem is that the generation of .project is done when importing a project in Eclipse, but is not updated in all cases later on. It's sad, and probably not permanent as the m2eclipse plug-in will improve, but it's true right now. So we end up having different configurations. What we had today was that: several natures were added to many projects on some machine, which then behaved much differently :-(
The only solution we see is to version the .project file (to avoid risks, we'll do the same for .classpath and .settings). That way, when one developer changes her pom, the local files get updated using m2eclipse, all of them get committed together, and other developers will see all changes.
Note : in our case, we use relative file names, so we have no problem to share those files.
So, to answer your question, I say yes, commit those files.
I also liked:
Rich Seller's answer
It seems like these project files can change over time as you work on a project so yes, I place them under version control.
ReplyDeleteYes. Everything but build output.
ReplyDeleteWe use IntelliJ IDEA, and keep '.sample' versions of the project (.ipr) and module (.iml) files under version control.
ReplyDeleteSomewhat bigger thing here is sharing and re-use than versioning, IMHO. But if you are going to share these configurations, what better place to put them than the repository, right next to everything else.
Some advantages of shared & versioned project files:
You can check out any tag/branch and start working on it quickly
Makes it easier for a new developer to first set up the development environment and get up to speed
This better adheres to DRY, which is always deeply satisfying. Before this, all developers had to set these things up every now and then, essentially doing repeated work. Of course everyone had their own little ways to avoid repeating themselves, but looking at the team as a whole, there was a lot of duplicated effort.
Note that in IDEA these files contain configurations such as: what are the "source" and "test source" dirs; everything about external dependencies (where are library jars located, as well as related sources or javadocs); build options, etc. This is stuff that does not vary from developer to developer (I disagree with this quite strongly). IDEA stores more personal IDE settings elsewhere, as well as any plugin configurations. (I don't know Eclipse that well; this may or may not be quite different.)
I agree with this answer that says:
You must be able to load a project
into a workspace and have in it
everything you need to properly set it
up in your IDE and get going in
minutes.
[...]
Load it up, set it up, go.
And we have it like this, thanks to versioned project files.