0

I'm trying to figure out which files to check in to version control when using Eclipse for Android development. I have a workspace with a single project. I found this which suggested that the .metadata folder did not need to be controlled (minus the comment there about launch params, however I don't mind re-picking those again on a different machine).

If I remove the .metadata folder then open Eclipse the project is no longer shown. I searched for posts on this symptom and they suggest re-importing the project. This solution doesn't make sense here, I'm trying to check in whatever is needed so another developer can open the workspace and see the project and work on it. Having them move the project then re-import it would be a bit messy.

So which files should I be version controlling so that someone else can get the latest and be able to open the project without controlling a bunch of user specific preferences?

Community
  • 1
  • 1
Nerdtron
  • 1,486
  • 19
  • 32
  • 1
    What do you mean "so another developer can open the workspace?" What if your other developers do not use Eclipse? You should only check in the Android project itself -- not the .metadata folder, not the .project or .classpath files either. – Thorn G May 05 '14 at 03:06
  • @TomG the other developers are using Eclipse in this case. So the goal is that they can go pull the latest from version control, open it in Eclipse, and be able to work with the project. There is not a need here to open the project in a different IDE. – Nerdtron May 05 '14 at 03:23
  • The workspace metadata still includes information about that user's configuration which is external to the project. It's a bad idea and most guides recommend against it. What will you do when you get conflicts in the internal Eclipse files? Why is the extra step of "Import project" after checkout so onerous? – Thorn G May 05 '14 at 12:39
  • @TomG If I exclude the .metadata folder then when opening the workspace in Eclipse the project doesn't show up. Not controlling anything in .metadata leaves you with the project not showing up. Import won't work directly because the project directory is already there. So you have to check out, move it out of the folder, then re-import it back into the workspace. Its just a cumbersome process which is why I posted the question :) Hoping there was something smoother like a way to tell Eclipse to recognize a project already in the workspace folder or something. – Nerdtron May 05 '14 at 15:59
  • 1
    If you check the project out using a wizard in Eclipse, it's smart enough to allow it to be checked out in the workspace. If you use an external tool you can check it out to a different directory and import it (I also believe you can tell Eclipse not to copy the project into the workspace). Either way, this seems penny-wise pound foolish. You're saving 90s of effort now to waste a few hours when the Eclipse files cause merge issues later. – Thorn G May 05 '14 at 17:21
  • @TomG I wouldn't say there's anything "foolish" about trying to streamline the process :) Just wanting to make it really easy for anyone to join the project and build with minimal steps and make sure I'm controlling what I need to control, etc. I think I've ended up with a workable solution based on the inputs given here. I'm keeping the workspace out of version control in a separate directory and then importing the project without the copy option. This way there's no moving and re-importing, etc. You check out, import without copy, and you're set :) – Nerdtron May 05 '14 at 18:55

2 Answers2

1

I have had similar experience using Eclipse for version control, and decided to quit using it because it is very annoying and buggy. Now, for git, I use SourceTree, which I prefer over eclipse version control. I think you should version control the source code folders, along with configurations, and other files you program needs to function, but never the executable files. If the other person is using Eclipse, for easiness, it is good idea to include the .classpath configuration file. If not, then the other person would need to clone the repository and make the required changes so that it works with his/her IDE.

Jorge Travieso
  • 11
  • 3
  • I'm not using any version control facilities built into Eclipse. I'm just trying to figure out which files I need to version control so another developer can get a fresh check out and open the project up in Eclipse with minimal hassle. I'm not controlling the generated binaries. – Nerdtron May 05 '14 at 16:00
0

I think I've settled on the following approach. This seems to work well so far and avoids some of the headaches mentioned in my original question.

1) each developer creates an Eclipse workspace on their machine somewhere, outside of version control; only the project directory is checked into version control - the workspace is completely uncontrolled

2) developers checkout the project directory from version control (in a different directory structure than where the workspace was created) and then use File >> Import, but they leave the "copy into workspace" unchecked.

So with the above, you can checkout from version control and work with the files right where they were checked out. There's no need to move them out then import them back in. When you import with the copy option unchecked, the workspace (which itself is not controlled) is just referencing the files where they're at on disk.

The only minor downside is that any workspace stuff has to be setup individually. Other articles mention controlling the launch params, but so far this hasn't been an issue - pretty easy to pick that once the first time you launch.

So anyway, hopefully this helps someone else :) This seems to be a reasonably smooth way to do it and avoids the issues we ran into initially.

Nerdtron
  • 1,486
  • 19
  • 32