S60 Open to new features

Without doubt, besides the eclipse editor, the Team features (version control) are the most often used features in my daily development grind. Given that, I am doing mostly java development these days writing Carbide plugins and test suites. For java development, version control is pretty straight forward. It's not quite so simple for Carbide development, but it can be done with just a little more effort. So at the risk of over simplifying or generalizing I'll give you a couple of ways of working with version controls systems and some things to look out for. I can't speak for all version control systems (we use CVS) but I think once you get version control going under an eclipse environment you'll wonder how you lived without it.

NOTE: The follow description will work with CVS and SVN; your mileage may vary with other version control systems. If so I'd love to hear any inaccuracies or improvements.

Basically there two types of users:

1) Those who don't want to check in any Carbide specific files (e.g. .cproject)
2) Those that want to keep Carbide project info around.

I'll give a basic work flow for each and how to get your files under version control.

1) Projects without Carbide Project Info.

The first rule for checking out a project is remembering that it will be checked out into your workspace. So you must adhere to the rule that your project sources need to be on the same drive as your SDK sources. If not, just select File > Switch Workspace > Other... and create a new workspace on the same drive as your SDK before you checkout.

Now when you check out your source-base for the first time, your version control system will just create a vanilla eclipse project like below. You can't do anything with it so just delete it (but don't delete the sources).

Now you need to import the project from the bld.inf, which lives in your workspace. That's it, your project is now a Carbide under version control (notice the server name and version numbers will appear in the file view).

2) Projects with Carbide Project Info.

Now for those that want to keep Cabride project information with version control all you need to add to your checkin is your .project and .cproject files. These files live at the project root. If you cannot see these files, check out the Navigator view, it will show you all the files that are filtered out, as below.

The same rules apply to building Symbian projects: your project sources must be on the same drive as your SDK. So for checkouts, the workspace must be on the same drive as the target SDK. The other strict rule you must follow when checking in/out .cproject files is that you need to have the same SDK 'id' attribute from devices.xml as was on the machine the project was checked in from. This is becuase in order for Carbide to know which SDK to target, it reads the configuration name and matches the source base with the SDK 'id'. If this rule isn't followed, then Carbide will be at a lost to find the correct SDK and you will see the configuration has a 'dummy_ID' in the name to let you know the configuration is invalid.