I have converted yet another googlecode Mercurial repository to Git – and as it took me (again) a bit too much time, here is my recipe:
Log into a Linux shell (Windows will hardly work – at least it didn’t work for me). If you don’t have some remote shell, download an Ubuntu VM and fire it up (you might need to install VirtualBox if you haven’t installed it already).
Check out your HG repo:
hg clone https://code.google.com/p/MyHgProject/
Check if you have to remap some author information:
hg log MyHgProject
If you want/have to remap, simple create an author map file
Get fast-export and convert your repo:
git clone git://repo.or.cz/fast-export.git
/path/to/hg-fast-export.sh -A ../authormap -r /path/to/MyHgProject
git checkout HEAD
Now change the source setting in your google code repository to git and push the local codebase:
git remote add origin https://code.google.com/p/MyHgRepo/
git push --all
At this point, your upload might fail with something like “error: RPC failed; result=35, HTTP code = 0″.
This can happen if your upload takes too long and this is a documented bug.
I simply solved this issue by pushig the git repo from a shell with a fast enough upload speed as my local connection obviously was too slow.
Now you might realize that you have “lost” your complete wiki – don’t worry, it’s still there!
Switch back your repo setting to Mercurial and repeat the process for your wiki which you can usually find at
That’s it. You should now be ready to use Git!
Thanks to following sites hedonismbot, scrambled tofu
One of the first lines a programmer will write in a new language is surely “Hello World”. In Java you can write to the console or to the error stream quite easy with a simple
System.out.println("Hello World") or
System.err.println("Hello Error"). Great! When the code grows, bugs creep into the code and make live a bit harder. At this point programmers should definately start a deep and loving relationship with the debugger that is delivered with the IDE instead of using
System.out/err.println() as debug method. Nevertheless – there are at cases, where a Debugger cannot (or hardly) be applied:
- The code runs in the IDE but not if startet directly. – What the hell’s going wrong?
- Handling of exceptions. An exception indicates a state that should not have happened and therefore it might be considered to be logged.
- The code is deployed to someone else and you cannot attach the debugger to his/her machine.
At either point, beginners tend to use
System.out/err.println() to trace the execution path. While this might be okay if the onlyone that is using the code is the programmer alone, this can be very annoying if you are working in a team: If you forget to remove the debug messages, you’re polluting someone elses console output. Even worse: if the code is deployed to a client which reports an error, you cannot raise/lower debug levels or just enable/disable debugging. Do you really want to send a “debug version”? (No you wouldn’t.)
I tend to upload my complete project into version control. This includes the sources, tests, Jars and also the nbproject directory where NetBeans stores the project configuration. By doing so, I can check out the project on a different machine and start quickly without having to configure the project.
Sources and API Docs of external libraries are not commited as they’re are not requried for compiling. I usually keep sources and docs in a separate place outside my project (let’s say
When I check out the project on a different machine I can do coding but I do have neither the sources nor the API docs. Even worse: as I’ve commited the whole project including the configuration, I have also commited the nbproject/project.properties file which stores the pathes to the source and docs. Which is not a problem if the pathes on all the machines are the same. But when a new contributer wants to join in, (s)he either has to use the same directory structure (and possibly the same OS) or he has to overwrite the settings. Both not very desirable.
For productive programming, I think it is absolutely crucial to also have both the API documentation and the source code of the according libraries available and integrated in the IDE in order to gain maximum productivity. Integrating the API and sources is pretty easy in NetBeans (as well as in other IDEs):
Right click the
Project > Properties > Libraries > select the JAR for which you want to link source and API and hit the edit button on the right.
Now you can select a folder, Zip file or Jar file for the API and sources, hit OK and you’re done.
Whenever you’re using a class from this library, you now can step into this class (by Ctrl-Clicking for example) or quickly jump to the API by pressing
ALT+F1 when the curser is at the corresponding class/method.
If you are annoyed by swithing between IDE and Browser or if you just forget the
Alt+F1 key combo that opens the browser with the correct API page, just enable the NetBeans inline Java-Doc viewer by selecting:
Window > Other > JavaDoc
This brings up a new panel which shows the JavaDoc comment of the class/method which is curently selected by the cursor. And you don’t even need to press any key for updating the view as it is updated automatically.
If it doesn’t work, I usually experience the following two errors:
- JavaDoc doesn’t work: If I perform
Alt+F1, the browser doesn’t open and the status bar on the bottom of the NetBeans window shoes a “Cannot perform Show Javadoc here”. Well – check the Path then. It should end in a directory that also contains the
index.html, package-list, allclasses-frame.html etc.
- The source is not displayed – even though the path to the Jar/Zip is correct! In that case, The Zip/Jar often contains all the source code in
src/mypackage/foo.java. NB expects only packagis in the Zip, so that the content list should look like:
maypackage/foo.java. So simply build another src.zip with the contents of “src/” (in this case) and you’re done.