I suppose I'll post a quick tutorial on "how to use git" and how it differs from SVN (and some of the reasons I think it is better).
Git is considered a "distributed SCM," in that each user gets a complete copy of the repository (compare to SVN where the only thing the user has is the checked out working copy). This means you can make changes, commit them, etc. without affecting the remote repository at all (and means you can break the code in your repository as much as you'd like without anyone else having to see). It's a lot faster because of the lack of network access for most operations and this also allows it to be more intelligent when doing things like merges (you don't have to specify the revision numbers to merge like in svn, since git has the entire history and all branches available to it since you have your own copy of the repository).
The basic workflow is the following:
1. First you would obtain a copy of a project by cloning the repository. The usual git 'convention' for projects is to have a separate repository for each project or module (as you can see by looking around
http://git.outpost2.net/). So for example, if I wanted to clone the SDK project I would do a
git clone git://git.outpost2.net/outpost-2/dll-api.git (the exact URL to use is shown in the browser on the site). This is analogous to svn co <URL>.
2. Now you would have a complete copy of the repository in the dll-api directory. You can make changes to files in the repo like usual and then do
git status to show the changed files; you add or mark files as changed using
git add filename. (The nice thing here is, unlike SVN, you do not have to commit every file that changes, when you do git add they are added to a 'staging area' and you can continue to modify them and update the file in the staging area with successive git adds, or only add certain files you want added to the commit).
3. You would do a
git commit to commit the files (you can also skip the above add step if you want to add all changed files to the commit with
git commit -a). This is not exactly the same like SVN, as it does not go out the server at all; instead it records this revision into the local copy of the repository (so you can go back and look at the log of changes with
git log and jump back to previous revisions and so forth). It would be comparable to having an SVN repository set up in a local directory and committing to that.
4. You would continue the above process of changing files, adding, and committing until you felt you had something you were ready to share with the rest of the world (git convention is to do commits for even very minor changes so you have more history in case you need to undo something, since no one else sees this yet).
5. Once you are ready to send your changes to the remote repository (i.e. the OPU git repository), you would do
git push to transfer your changes to the server. Similarly, you can get changes made by other users by doing a
git pull which is much like doing an svn up command.
Unlike SVN, git has support for real branches and tags; you can create a branch by doing
git branch branch-name, switch between branches by doing
git checkout branch-name, and merge changes from other branches into your current one by doing
git merge source-branch. All of this is tracked and there are GUIs that can show the exact tree of branching and merging.
Additionally, the software we are using allows you to make 'private clones' of a repository that are stored on the server, if you want to make more extensive changes without affecting the mainline repository.
Now to answer some of your questions: there are separate repositories for each project, not one big huge one. As far as "sub projects" that referenced higher level directories in the SVN repository, you can get a similar behavior using the git submodule series of commands (basically this clones a separate repository into a subdirectory and treats that subdirectory like a symbolic ref to a specific version of the other project; for example this would make sense for libraries or for shared includes like the API). It would probably be a good idea to set up these projects in such a way (otherwise, there are some other tools that "wrap" around git as well that perform similar functions; one you may have heard of is called "repo" and downloads git projects into a certain directory structure as defined by a manifest; the Android open source project is an example of a use of this where around 160 different git repositories get combined into a monolithic directory structure and managed by repo).
In the end, I think git is a little different to work with (I wouldn't say hard per se since there are some pretty big advantages over SVN, IMO, it just takes a bit of a shift in thinking as opposed to the way SVN works).
