I just love it. Thank you so much!

Link: Andy Maleh – Code Painter: Mouse-less Eclipse

If you could answer all these questions with a “yes” you might have noticed afterwards that you can’t do anything with this project because eclipse created it as “general project”, meaning no java, php or anything other specialized nature. This results in certain functions like Run as Java application not being accessable.

There are several solutions to that problem – but most of them are really ugly, imho. But since I don’t want to keep anything from you I will explain these methods too. So let’s get started…

The wrong way

The intuitive way you propably would start the task “to checkout a new project from SVN” might be “File -> New -> Project -> Others…-> Checkout a project from SVN”. In the result you’d have the previously mentioned “general project” which is pretty useless.

solution #1: edit .project

After the creation of the new project you quit eclipse, browse to the project folder in your file system and open the .project-file in a editor.

You’ll find these lines:

<natures>
</natures>

Change it to match:

<natures>
<nature>org.eclipse.jdt.core.javanature</nature>
</natures>

Save the file and fire up eclipse again, you will have your svn-project recognized as Java-project. This solution might be quick but the drawbacks are the quit/edit/start-sequence outside of eclipse and the necessity to find the right “nature” for your svn project.

solution #2: delete and recreate

After having completed the checkout you will delete your project. Yes, you read right. (I told you these methods are ugly! ) But when deleting be sure you don’t check the box for physically deletion of the files (so they’ll remain inside your workspace).

When you finished deleting the project you create a new project for the kind of project the svn project should represent (i.e. java, php etc.). While in the creation wizard be sure you select the same folder where the svn project has been checked out into.

The newly created project will have the right project type and will contain all files from the repository. Sometimes it is necessary to refresh the workspace (windows: hit F5 on the project).

Although this method also results in having the right data with the correct project type it has a bad taste jumping through these hoops in order to finish a simple task like that.

Since I wasn’t pleased with all those solutions I kept on looking. Finally I found…

The right way

Besides the following solution is the one most hoopless (no pun intended) the claim “right” is justified because it seems that this is the way the eclipse devs want us to check out a project.

In order to accomplish the task at hand you have to

• open the SVN Exploring-perspective
  ( Windows -> Open Perspective -> Other… -> SVN Exploring)
• create a new repository location or select the desired source
• browse to the parent folder of your new project (e.g. trunk)
• right click on the folder, choose Checkout…
• in the new dialogue you will have the chance to select Check out as a project configured using the New Project Wizard, take that chance, fill out the rest as you please and hit Finish
• in the new project wizard which will open next you can choose your desired project type (e.g. java) and set up everything like you would in a normal project (e.g. compliler compliance level, JRE, related projects etc.)
• after hitting this finish button you will notice that the svn is queried to retrieve the code
• and you’re done!

In my opinion this way is the most hazzle-free way to check out a new project though I love to see it the other way around too (New->Project->New Project from SVN -> yada yada yada -> “Please select a project type or press OK to let it remain a generel project.”). Until this is implemented I will go with the second best solution.

Have a good look a the compiled list and be sure to bookmark it for the next crisis with TSVN…

Link: Subversion and TortoiseSVN tips and tricks.

svn switch --relocate <oldUrl> <newUrl>

Mind that “oldUrl” and “newURl” have to be full addresses, not some kind of subdirs or relative to another.

Juist to mention it: Subversion 1.4 and 1.5 repositories are not backwards compatible and whenever you use a 1.5 client to check something in there is hardly any way to move back to 1.4 (and 1.4 clients won’t work with the repository anymore).

You might remember sentences like “But it worked yesterday!” or “Why the hell did I change that and when?” which were common companions when I looked at code I wrote a while back.

To avoid situations like this, a version control system could be a valid solution with more benefits than just less confusion.

Ernie Leseberg made the effort to collect most of the reasons I could think of on why to use a VCS with a small team or even if you are working alone.

If you don’t use a VCS yet give the article below a read and hopefully you will change your mind.

Link: Why use version control for solo developers or small teams