What goes into Source Control?

Question

Given: http://developer.android.com/resources/faq/commontasks.html#filelist

1. What are the best practices for getting your projects into source control? I ask because if you simply right click on your project, choose team, etc. you end up with the /bin & /gen folders, .classpath as well as all the Eclipse related items.
2. If I'm inheriting a project with .../workspace/projectName et al. included how can I clean that up to include only the items relevant to the aforementioned URL?

Yasmin

Answer 1

I summarized all my findings in a blog post that can be found here: http://www.aydabtudev.com/2011/05/what-goes-into-source-control-android.html

I executed the following commands from within my project folder to get them out of source control:

svn rm --keep-local .classpath
svn rm --keep-local .project
svn rm --keep-local default.properties
svn rm --keep-local proguard.cfg
svn rm --keep-local bin/
svn rm --keep-local gen/

Then I executed the following command to add them to an ignore list:

svn pe svn:ignore .

Add each item above without the associated command like so:

.classpath
.project
bin/
...

I followed that up with a commit and an update to solidify my changes.

svn commit -q -m "Removing files" .
svn update

It would seem the smarter way to do this would be to configure the Ignored Resources under the Eclipse Team preferences.

Yasmin

I think you do want to check in .classpath and .project files, though. – Roadstead

@DanielYankowsky Eclipse & ADT have gotten much better about handling those 2 files from source for sure. .classpath in particular used to give me fits switching between a Windows and Linux machine. Also, I never wanted to assume the person receiving the source code was using Eclipse as their IDE. – Yasmin

Fair enough. I was assuming that you were talking about a team environment where everybody was using the same IDE. – Roadstead

Answer 2

If you're using SVN, you should selectively add files/directories to your repository.

For example with the following directory structure (quick example from my disk):

res/
src/
build/
.idea/

You do not want the build directory, nor the personal preferences for your IDE (.idea folder) adding, so you would only issue the command: svn add res src

To (I think) answer your second point, I'd manage everything to do with version control from command line initially, and then let your IDE do it.

My apologies if I'm missing the point of the question.

Fetich

Answer 3

Here are some basic points:

• Don't store stuff in version control that your source code produces. For example, if you build a jarfile, don't store that jarfile under source control.
• Source control is for source. If you have releases, use a release repository like Artifactory. Don't let the Maven stuff scare you away. Maybe you don't use Maven (now), but a Maven repository tool is in standard format, and makes it easy to find your releases. Artifactory can work with Ant/Ivy, and with a little elbow grease, you can get it to work with C and C++ projects too.
• Which brings me to the next statement: Don't store your jarfiles (if you're a Java project) in your source repository. It's convenient, but you'll end up hating yourself for it in the long run. Binary files take a long time to process in many source control systems and they can take up lots of room. What's even worse is that you lose information about them. For example what version of common-utils.jar is checked into Subversion that my project now depends upon. Again, use Artifactory and Ant/Ivy or Maven. If you're non-Java, you can use wget or curl to fetch your dependent libraries out of Artifactory. Again, don't let the whole Maven thing scare you.
• If you have a Java project, and you don't use Maven, insist that code is stored in the repository using Maven's standard layout. That is, Java code is stored under src/main/java and non Java files are under src/main/resources. The advantage is that it makes it easy to move from project to project, and new developers can quickly find where things are. Plus, it makes your build.xml files much cleaner. You can use any standard repository layout you want, but by insisting on Maven's standard, you can squelch all complaints. "Hey, I agree with you, but Maven says you put your code under this directory. Sorry, I wish I could help, but my hands are tied"
• If you're using Subversion, stick with the standard, trunk, branches, tags style and don't be too fancy. I'm not 100% crazy about the layout myself. (I'd rather have a main under the branches directory and no trunk), but you'll simply confuse developers and make support more difficult, and all for very little gain.
• Make sure all projects (if you're using Ant) have standard target names. Again, I borrow Maven's naming convention. Make sure all build.xml use the description parameter in target names, and that internal only targets don't use description. That way, ant -p works. Also make sure that all built artifacts are under the target directory (again, Maven's way). It makes it easy to do a clean if you only have to delete the target directory. The idea of clean is to restore your layout to pristine checkout condition. Makes it much easier to use a tool like Jenkins. Which reminds me...
• Use a continuous build tool like Jenkins. It helps you enforce your policy and standards. Unlike many tools, developers actually like Jenkins. And, you can add stuff like automatic testing, checkstyle, etc.

Rod

"Again, don't let the whole Maven thing scare you." Why not, Maven is scary! Plus, it's standard code layout is awful, just the worst. Well, tied for the worst with "put everything in one directory". – Toll

Artifactory supports customized layouts and is not Maven specific anymore. – Unfortunate

Answer 4

1. It depends on your workflow. If you expect everybody who will ever work on your project to use eclipse having the .classpath folder in there is good because it keeps all your settings(library paths, external dependencies..)

To the best of my knowledge subclipse doesn't put the /bin folder under version control(it probably happened because of the weird way the repository shaped as you describe in 2.) because eclipse can generate that one on the fly as soon as it has the /src folder.

1. usually moving everything under /workspace/projectName to / and deleting /workspace is sufficient.

Resile

Both the /bin and /gen folders ended up in source control as well as .project, default.properties and proguard.cfg. This was done through the method listed above: right-click project->team->Share Project ... Having the .classpath under source causes grief when you have multiple developers on varied platforms and no control over their path structure. – Yasmin