Hello David and all,
Few comments, hopefully helpful:
Regarding "histories":
The histories in this context is the commit logs of the existing project,
i.e. the date, author, and diff to the source code files.
You can see the current history (of the SVN repo) by doing:
svn co svn://svn.sv.gnu.org/gnuspeech
cd gnuspeech/
svn log | less
If you decide to copy the files as is, and start a new git repository,
those entries will not be preserved in the git repository.
When someone will do "git log", the first entry will be
you (presumably) on Sept-2015 committing all the files.
Depending on your POV, it might be perfectly acceptable to 'reset' the history,
start fresh, and mention in a README that all previous commits are available
from the
(now stale) SVN repository. You can keep the SVN (and CVS) repositories
available forever on Savannah.
Alternatively, there are tools to import an existing CVS/SVN repository into a
GIT repository.
The advantage: you preserve the rich and detailed commit history.
The disadvantage: the repository is not started in a 'clean' state which allows
you to carefully determine what goes in (everything that was in the SVN will be
in it initially).
IMHO there's no one "correct" approach here, it's a decision you'll need to
make.
---
Regarding multiple independent git repositories and submodules:
I agree with previous commenters, you can decide to have:
1. one big repository with everything
2. multiple git repositories, but keep them completely independent
3. multiple git repositories, and set them as git submodules.
Each has its own advantages and disadvantages.
The "guix" example I wrote about - is case #2.
The related guix repositories (eg. guix/dhcp.git) are related just by being under the
"guix" directory.
Users can pick-and-choose which repository they are interested in.
Example of case #3 is GNU coreutils, which uses gnulib as a git-submodule.
If a user runs:
$ git clone --recursive git://git.sv.gnu.org/coreutils.git
It will also pull files from the submodule at git://git.sv.gnu.org/gnulib.git
Again, IMHO there's no "correct" answer.
---
Regarding experimentation:
Yes, the best option is to experiment (current with another, non-savannah
service).
That is simply because on these services you can create and delete repositories
over and over again,
until you are pleased with the result.
But in the grand scheme of things,
pushing a bad commit to savannah is not the end of the world.
It simply means you'll need to push another commit, undoing the previous one.
The main disadvantage is that you end-up with a messy repository (and
potentially a very large one).
(Other hosting services allow you to do a "force push" or non-fast-forward
commit, which literally removes the bad commit from the history.
This is cleaner, but opens the door to code removal. Savannah does not allow
it).
regards,
- assaf
