Develop Reference

Include/exclude IDE-specific configuration files from Mercurial version control

The IntelliJ 2017.2 documentation suggests including the .idea folder that contains that IDE’s own configuration files (excepting the workspace.xml and tasks.xml files). I can understand the sense in this, as I could incorrectly configure the project settings and want to revert.
Yet, I want to post this open-source multi-module Maven-driven project to BitBucket for public access. Obviously, not everybody uses IntelliJ as their IDE, so I do not want to force my IDE settings on them.
➠ How do open-source authors resolve this conundrum?

My suggestion that comes from experience is to always explicitly ignore (that is, add to .hgignore or .gitignore) IDE configuration files or directories.
It is not only a question of not spamming a project with configuration files for a specific IDE. The real problem begins when more that one person uses the same IDE. Depending on the IDE and on how it is configured, you can fall in a situation where each commit contains changes to these files, and will confuse all the other developer using the same IDE, which in turn will overwrite the changes again in a infinite loop.
Some of your IDE settings will be global and stored in your home directory. The ones that are project specific will survive as long as you don't change the local directory in which you cloned the repo. If you change directory, in my experience it is always tolerable to reconfigure the IDE. There are at least two situations when the local directory changes: (1) you remove the directory and clone the repository again (2) you use more than one computer.
If you are concerned for things like coding style, then the best approach is to use a command-line formatter tool that works for any editor or IDE. That tool will have its configuration file committed in the repo, since coding style is something that should be equal for all developers and files of a repo.

How can I commit only a single .java file to git from an eclipse project?

I want to commit only a .java file to an already existing repository. I am using github for a class, and we are each given access to a private repo containing project information. I am supposed to add only a .java file to this repo, but I can't figure out how to do this. I have come close: I committed only the .java file, but it is inside a directory with the same name as my eclipse project.
Is there a way to commit only the .java file, without any of the project information, while keeping the project usable?
Thanks.
edit:
My goal is to have \git\repoName\MyFileName.java
as well as keeping the files already in \repoName\ and keeping the MyFileName.java in a usable eclipse project.

Is there a way to commit only the .java file, without any of the project information, while keeping the project usable?
yes, you will need to create a .gitignore file, and put the rest of your project into the gitignore file, (and also gitignore itself), that way, the only files that are tracked by git are the .java files.
As for the files being inside the directory with the same name as your project, take a look at where you cloned the git repo to, and make sure it is on the same level as your project files.
Take a look at this documentation
http://git-scm.com/docs/gitignore
https://help.github.com/articles/ignoring-files/

I think its much simpler than what you are expecting :)
You can do, git add, docs:
git add yourFileName.java
Now you can commit the .java file
git commit -m "I am updating only .java"
You can either reset or let it be as it is!!
git reset
reset will not have any history. So, be careful if you want to reset. In this scenario I think you dont have to reset. See here for some help.
See my answer on how to push/pull changes from eclipse into github. Let me know for any help on how to interact with github on eclipse.
You want to remove a subtree and create a new repo?
This is definnitely possible but you have to be careful. Creating a subtree only for file like yourFileName.java surprizes me a bit, but why?
For whatever reasons, see this for an easy way, and the original post is this Detach (move) subdirectory into separate Git repository
This blog might also help you.

I figured it out!!
The key was to add a source. You can do it when you create a project, one of the options will say "Link Source" or something along those lines.
You can also do it after a project is created:
Right click the project in Project Explorer. Go to Properties -> Java Build Path (on the left) -> Source (the first tab) -> "Link Source..."(button on the right)
Then just browse for the git repo folder that you already have and you're good to go! Just create new class files within /repoName in Project Explorer.
If anyone needs clarification or anything, let me know.

How to use different sets of property files on a build server and on developers' machines?

I have a web application. I'm configuring CI for it.
We didn't use a build tool (neither Ant nor Maven), and made builds by means of IDE.
Now I'm working on an Ant script which will be used by our build system.
There are several property files which should have different properties' values when the project is build on the build server but not on local machines.
What are the common approaches for handling such situation?
If we used Maven, I would probably go with using different profiles, but we have Ant.
One possible solution which I can see is creating a root folder for all property files sets, and storing each set in a separate subfolder (see the schema below).
/profiles
/dev1
prop1.properties
prop2.properties
/dev2
prop1.properties
prop2.properties
/build-server
prop1.properties
prop2.properties
/webapp
/WEB-INF
Then during the Ant build we can copy the correct set to the correct location. But it can be a problem to make builds by IDE as we used to do (because property files are not stored in their proper place under src folder any more).
Are there any other approaches?

If I understand you, you build separate ear/war/jars for each and every environment on your continuous build server. Is that correct?
I have two ways I handle this: The Smart Way, and the Dumb Way:
Smart Way
The smart way is to configure your application server (JBoss, Weblogic, etc.) to look for the desired property file external to the jar/ear/wars that are installed in the application server. This way, you build one set of jar/ear/wars, and it works everywhere. Plus, you do something very, very important: You cause the Finger O' Blame to point elsewhere.
If the properties files are packaged as part of the jar/ear/war, and something on the server changed, you'd get the blame because the your build was bad. Sure, you had no way of knowing the they changed the environment, but you did install that bad build file on the production server.
However, if the properties are stored outside of the build artifact, then it's the team responsible for configuring the servers that's at fault.
Actually, it's a lot easier for the team responsible for configuring the application server to handle the issue. They know what got changed, and they can update the properties file to reflect that change. Not only that, but you're only having to build and distribute a single set of artifacts. You don't have to worry if a new environment is setup, of if something in the old environment changes. In fact, changes can easily take place without forcing you to do a new release.
Dumb Way
We were able to do things the Smart Way at my last company. At my current company, we do things the Dumb Way. The properties are embedded in our build artifact, and there is no easy way to change it.
I divided each set of properties files by suffix instead of different directories (i.e build.properties.dev1, build.properties.dev2, etc). We placed properties files were put in a single directory.
When I do a build, I use the AntContrib <for> task to loop through the build process multiple times, each time with a different properties file. I then build an artifact for each and every set of properties files. I use the suffix on the properties file as folder names in my target directory where I store the built artifacts. That way, each build produces all the artifacts for all the environment.
That way, if the artifact worked in the dev environment, it will work in QA and Production. The only problem is that I'm storing 5 to 10 times the number of artifacts on my Jenkins server, so I need 5 to 10 times the disk space.
By the way, as long as I can define a <fileset> to find the properties files, I can use the <for> task, so you can use the different directories. And, you can use <basename> to pluck off the directory names.

How to set up a subvresion repository from my netbeans project

I was recently given some code that was worked on by someone other than myself, and after lots of work involving hunting down external dependencies, and editing the build.xml file to get ANT to build things in a sane way, I'd like to now get the code into a subversion repository.
The team I'm working on is rather small, but the members on the team change often. So I want people to be able to start working on this code as quickly as possible. A simple checkout from the repository, and opening the project in Netbeans to have everything building and executing properly would be ideal.
How do I achieve this when there are external dependencies that are not going to be on other team members machines?
Should I place the libraries my project uses in the VCS?
How do I instruct subversion to not track generated files such as class files and jar files?
Should binary resources that are unlikely to change such as images and sounds be placed in the VCS? If not what would be the best way to distribute them?
Thank you.

1) yes. Anything needed to build and deploy the application and isn't generated by the build process goes into version control (yah, I know the maven fanz don't like that).
2) make sure everything that's generated goes into distinct directories that you exclude from version control.
3) see 1). Same thing. Same with project documentation, release notes, etc. etc.
The biggest problem of course are directory names which will be set in your IDEs configuration files and differ between development machines.
Not just the location of the project directories, but the IDE itself, JDKs and other tools, appservers, can all be different between machines. It's a constant problem.

I usually use maven cause you can have a repository for jars and dependencies this makes life easier, but since you have already refactor your code to use ANT maybe this is not what you want, to use subversion with netbeans then you might want to add another folder for jars like libs or something and then another for the binaries like audio etc. Also check for the svn plugin for netbeans it will add the ignore to the dir and just update java files.
To add files to ignore you can use
svn propset svn:ignore -F .
or you can look for the config file in your subversion home and add something like this
global-ignores=*.classs
Hope this helps

How to maintain base files for development environment central while allowing people to change their local copy

what I'd like to do is have files in a central location so that when I add people to my development team they can see the base version of these files but meanwhile have the ability for the rest of the team to work with their own local version.
I know I can just put the files in source-control (we use Tortoiese-SVN) and have my team change the local versions but I'd rather not as the exclamation mark signaling the file has been changed and needs to be committed, quite frankly, irritates me greatly.
I'll give two examples of what I mean:
We use quite a few build.xml files which relate to a single properties files which contains many definitions. Some of them can be different between team-members (mainly temporary working directories) and I'd like a new team-member to have the ability to get the properties file with the base config but change it if they wish.
Have the eclipse settings file in the SVN so that when a new team-member joins they can just retrieve the files from the server and have a base system running. If they wish they will be able to change some of these settings.
Thanks,
Ittai

What I have done in the past is having the file in a different location or with a different name inside the repository with an ignore real_file rule so that the subversion will not complain on the changed file, and have a small script that will copy the files to the concrete location.
For example, the .project Eclipse project file can be named eclipse-project-default in the repository. When a user downloads the local copy they run the script and they get a fresh .project (copy of eclipse-project-default) that they can change and will not show in the subversion status command.
The problem with this approach is that it is often easy to make a change to the file that should go to the central repository and is forgotten. The approach requires changing the actual file, and applying the same change to the config file that is actually uploaded. And then commit that change.

This really is a case for version control as you point out, but having said that I guess you could put a copy in a central file server and have them download it from their. You may even want to make this a read only file or directory.
If the status indicator bugs you that much you can set this file to be ignored by your version control system.