Create a users file (i.e. users.txt) for mapping SVN users to Git:
user1 = First Last Name <email@address.com>
user2 = First Last Name <email@address.com>
...
You can use this one-liner to build a template from your existing SVN repository:
svn log -q | awk -F '|' '/^r/ {gsub(/ /, "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > users.txt
SVN will stop if it finds a missing SVN user, not in the file. But after that, you can update the file and pick up where you left off.
Now pull the SVN data from the repository:
git svn clone --stdlayout --no-metadata --authors-file=users.txt svn://hostname/path dest_dir-tmp
This command will create a new Git repository in dest_dir-tmp and start pulling the SVN repository. Note that the "--stdlayout" flag implies you have the common "trunk/, branches/, tags/" SVN layout. If your layout differs, become familiar with --tags, --branches, --trunk options (in general git svn help).
All common protocols are allowed: svn://, http://, https://. The URL should target the base repository, something like http://svn.mycompany.com/myrepo/repository. The URL string must not include /trunk, /tag or /branches.
Note that after executing this command it very often looks like the operation is "hanging/frozen", and it's quite normal that it can be stuck for a long time after initializing the new repository. Eventually, you will then see log messages which indicate that it's migrating.
Also note that if you omit the --no-metadata flag, Git will append information about the corresponding SVN revision to the commit message (i.e. git-svn-id: svn://svn.mycompany.com/myrepo/<branchname/trunk>@<RevisionNumber> <Repository UUID>)
If a user name is not found, update your users.txt file then:
cd dest_dir-tmp
git svn fetch
You might have to repeat that last command several times, if you have a large project until all of the Subversion commits have been fetched:
git svn fetch
When completed, Git will checkout the SVN trunk into a new branch. Any other branches are set up as remotes. You can view the other SVN branches with:
git branch -r
If you want to keep other remote branches in your repository, you want to create a local branch for each one manually. (Skip trunk/master.) If you don't do this, the branches won't get cloned in the final step.
git checkout -b local_branch remote_branch
# It's OK if local_branch and remote_branch are the same names
Tags are imported as branches. You have to create a local branch, make a tag and delete the branch to have them as tags in Git. To do it with tag "v1":
git checkout -b tag_v1 remotes/tags/v1
git checkout master
git tag v1 tag_v1
git branch -D tag_v1
Clone your GIT-SVN repository into a clean Git repository:
git clone dest_dir-tmp dest_dir
rm -rf dest_dir-tmp
cd dest_dir
The local branches that you created earlier from remote branches will only have been copied as remote branches into the newly cloned repository. (Skip trunk/master.) For each branch you want to keep:
git checkout -b local_branch origin/remote_branch
Finally, remove the remote from your clean Git repository that points to the now-deleted temporary repository:
git remote rm origin
You have two options for this. The one you already mentioned, and that is to have a trunk for each project (option 1):
https://simucal-projects.googlecode.com/svn/projectA/trunk/
https://simucal-projects.googlecode.com/svn/projectA/tags/
https://simucal-projects.googlecode.com/svn/projectA/branches/
https://simucal-projects.googlecode.com/svn/projectB/trunk/
https://simucal-projects.googlecode.com/svn/projectB/tags/
https://simucal-projects.googlecode.com/svn/projectB/branches/
Option 2 would be to have one trunk with each project being a subfolder under trunk:
https://simucal-projects.googlecode.com/svn/trunk/projectA/
https://simucal-projects.googlecode.com/svn/tags/projectA/
https://simucal-projects.googlecode.com/svn/branches/projectA/
https://simucal-projects.googlecode.com/svn/trunk/projectB/
https://simucal-projects.googlecode.com/svn/tags/projectB/
https://simucal-projects.googlecode.com/svn/branches/projectB/
The advantage of option 1 is that you can branch and tag each project independently. This is desirable if you need to deploy each project seperately.
Option 2 is desirable if all the projects are deployed together. This is because you only have to tag the repository once when deploying.
Since you are using Subversion for school projects, you need to ask yourself whether you will ever need to tag your work. You can also ask yourself whether you ever need to create branches (you probably would want to if you want to experiment a bit). You will also need to ask yourself whether you are happy to branch ALL your work together as one, of whether you prefer the flexibility of branching each project independently.
The rule of thumb that I always follow: trunk together whatever we deploy together.
(By the way - you can have many trunks in the same repository - this is almost equivalent to having one trunk in multiple repositories, except that each repository maintains its own revision counter and you cannot merge between repositories.)
Best Answer
Tagging is cheap, and takes almost no space in repository. I wouldn't worry about having extra project in some tag folder, but you can always remove extra projects after the tagging.
That being said, I actually prefer the first approach, because you have more freedom there. Freedom comes with a price, but the price here is small.
EDIT: Tagging and branching are essentially the same operation in SVN. When you branch some folder you are creating a snapshot-copy of that folder. This "snapshot" part is important, because any changes in original folder will stay there, and will not propagate to branched folder. Only difference between tag and branch is that SVN client will warn you about changing something in folder whose path contains "tag".
So, any of the two options is tag-safe in regard to the issue of changing the contents after the tag. Tag folder will not be changed, only the folder where you actually made the changes.
EDIT2: You may consider a third option:
Your working folders are
Solutions/Solution_1/trunkandSolutions/Solution_2/trunk. Those folders are essentially empty, but they containsvn:externalsproperty that is set up to appropriate trunk folders. When you want to branch or tag something you make branches in Modules/Project_X folders, and then make a branch in Solution_X folder withsvn:externalsproperty changed to new appropriate folders. Tagging is the same as branching, but you would "fix" the revision of every external.