SCM

The migration from CVS to SVN (Subversion) and Git wasn't that hard. Git is the way for me to go on. Working with Git in parallel with SVN is not a big problem, but I wish to find better UI-applications for Git, something like TortoiseSVN. And better Git integration into Eclipse & Netbeans is needed.

Git, as distributed version control, have a cool branch / merge functionality to the level, where the writer is encouraged to do branches on the fly voluntarily and often. Especially private local branches are handy just in case of testing different variations e.g. of the source code.

One of the great findings was GitHub, where a lot of OpenSource projects are hosted with Git. It's easy to start up your own project there by commands push/pull/fork and clone. The only thing to remember is, that _free_ GitHub is a public repository like Google Code (http://code.google.com/hosting/).
Anyway, it is as easy to manage GitHub repository and fetch projects down as it is to manage local repositories on your own drive. Eric Berry's GitHub presentation.

And the most interesting function in GitHub is to find out the most popular Open Source projects by number of forks and how many people are watching the status of each projects. Awesome tool :)

The most challenging step will stay just the same: merge. If there are lot of changes into same files made by several distributed team members to merge at once, problems are the same. Git only can help in this case by making frequent merges to HEAD-branch easy.
Making frequent merges a standard approach the release management can be much straightforward. At the same time it will be a standard procedure to communicate division of work and architecture frequently to avoid overlapping changes. One way is to divide merge in lower level to be done in stages like in Linux-kernel project. Git supports agile way to work. Let's see, how much companies can utilize Git.