Recently I needed to build an Android project on a server without a GUI and Eclipse. The Android DEV site focuses on building Android projects using Eclipse, and so did not have much information on how to do this, so I created added a new HOWTO page on my wiki:
Subversion is pretty mainstream these days. Luckily, git can work with a Subversion repository just fine. So, just because your workplace is using Subversion as the central repository, you can work with it using git if you want. Using git you can checkout from Subversion, use it locally enjoying all its benefits, and occasionally commit your work back to Subversion.
Let me give you some real practical reasons why you absolutely should use git instead of Subversion on the client side:
- With git you have the complete revision history locally. History operations do not need network access, and are therefore very fast. (You do know that git is the fastest version control system out there.)
- All commits are local, not automatically applied to the central repository. This way you can break down large tasks to several smaller commits which, being local only, will not have side effects on others. Temporary instabilities introduced by your changes as you make progress will never affect your coworkers. After your feature is completed and stable, you can push your local commits to the central Subversion repository.
- Creating local branches is easy and efficient. In git you can have multiple branches living inside the same working directory, and switch between them easily. This makes it very easy to switch between different tasks, or trying different implementations of the same task, without creating unnecessary copies of the project’s workspace. Subversion handles branch operations very poorly, so you might not be used to using a lot of branches. Git handles branch operations very well, and you once you get used to branching often, you will benefit greatly from it.
- Subversion litters all sub-directories of the project with
.svndirectories. Git works differently, there is a single
.gitdirectory in the project’s root directory. Among other things, a nice side effect of this is that you can easily do things like
In short: if you are using a Subversion client instead of git, you are really missing out on a lot of benefits git could bring to you.
- Git is cross-platform (works on Linux, Windows, Mac)
- There is a nice plugin for Eclipse, and probably most other major IDEs as well
- On Windows it comes with a superb bash terminal and other core unix tools, which is a lot leaner than a cygwin beast when all you need is bash, awk, sed and perl…
What’s the catch?
- Eclipse integration does not work as well as Subversion:
- The Team Synchronization function may not work well, depending on the repository. In particular if the line endings in the project are not consistent, using a mixture of windows-style and unix-style line endings.
- I don’t know how to do
git svn rebaseand
git svn dcommitfrom Eclipse itself, so you might need the command line for that.
- You really have to spend some time to learn it properly. Git has a unique way of thinking which is different from Subversion. You will need to understand git before you can use it effectively.
- The first checkout takes a lot longer compared to Subversion, because git gets the entire repository history. But this is something you only need to do only once. As a nice side effect, you will have a backup of the central repository. Should the central repository die a horrible death, it could be rebuilt from a git checkout.
- http://git-scm.com/book - The official git book, completely free PDF and ebook versions
- git –help
- Why not use Git?
Mac OS X 10.5 (Leopard) comes preinstalled with Apache 2 and PHP 5, you just have to enable them.
To enable Apache, open System Preferences, go to Sharing and put a check in Web Sharing.
To enable PHP:
- Edit /private/etc/apache2/httpd.conf, uncomment the line LoadModule php5_module
- Copy /private/etc/php.ini.default to /private/etc/php.ini
- Restart Apache (uncheck and check again the Web Sharing box in System Preferences / Sharing)
Find Bluetooth devices nearby, this assumes the devices have been configured to be discoverable:
hcitool scan --refresh
This will print the MAC addresses and names of the devices within range. For example:
00:07:80:93:54:1C MAGIC_2311 00:23:D4:1E:32:f1 Androidx001
Connect to a Bluetooth device using the MAC address like this:
sudo rfcomm connect 0 00:07:80:93:54:1C 1
A screen should pop up asking you to enter the PIN for pairing. (With many devices the PIN is as simple is 1111 or 0000 or 1234). If pairing was successful, you should see a message like this in the terminal.
Connected /dev/rfcomm0 to 00:07:80:93:54:1C on channel 1 Press CTRL-C for hangup
You can use a graphical client such as
cutecom to connect to
/dev/rfcomm0 and communicate with the Bluetooth device, see incoming data and save it to a log file.