Some notes regarding using git as a replacement for CVS
Conversion
Tools Used
To convert dist-cvs to git repositories, I make use of:
- git-core - In Extras.
- git-cvs - In Extras
- cvsps - In Extras
Layout
The current layout I'm using is rougly the same as dist-cvs: <packagename>/<release-dirs>. I've omitted the rpms/ dir for now, as it may become an alias to getting all rpms. With CVS, the package dir was basically the module, and each release directory was just a directory, even though we call it a 'branch'. For git, I've made it so that each release directory is it's own local clone of the package repo. This allows for "branch" confined logging and history, as well as making it easier to setup ACLs. Since git doesn't let you keep a repo of local repos very easily, each package 'module' is a repo itself just containing a file named 'branches' that is a list of all the release branches that exist for that package.
How to Convert
I had /cvs/extras restored from backup to the xen host under /cvs/extras.
The conversion tools need both the CVSROOT __and__ a checkout of the content to do proper conversion. I setup a directory structure as such:
/cvs/extras/ dist-git/extras/
- /cvs/extras/: holds CVSROOT and the rpms/<package> trees from the CVS server
- dist-git/extras/: landing zone for converted modules
Basic workflow:
cd dist-git/extras/ mkdir <packagename> git cvsimport -v -d /cvs/extras/ -C <packagename>/<releasedir> <packagename>/<releasedir> cd <packagename>/<releasedir> git repack -a -d
One would loop through each releasedir of each package (or at least devel/ FC-6/ FC-5/ FC-4/ FC-3/), git init-db the <packagedir> and git add/commit the branches file. It will also repack/prune the git metadata as the import doesn't seem to do this. This saves a LOT of space. I've converted all of extras package CVS as well as the common module. The quick bash string I used was:
for rpm in <code>ls /cvs/extras/rpms/</code>;
do mkdir ${rpm};
for branch in /cvs/extras/rpms/${rpm}/{FC-[3456] ,devel};
do git cvsimport -d /cvs/extras/ -C ${rpm}/<code>basename ${branch}</code> ${rpm}/<code>basename ${branch}</code>;
done;
pushd ${rpm};
for dir in *;
do echo ${dir} >> branches;
pushd ${dir};
git repack -a -d;
popd
done;
git init-db;
git add branches;
git commit -m 'add branches';
rm branches;
popd;
done
Time to convert all of extras was:
real 556m51.452s user 32m36.370s sys 68m29.753s
Size after converstion:
3.9G /srv/git/extras
Server Setup
File system and Permissions
git can be accessed via http, ssh or the git protocol. In my test server, I created /srv/git to serve up the repositories. I created a group 'fedora' and set group sticky and write bits on /srv/git.
Work Needed
These are some of the high level items that need to be investigated or implimented. If you wish to help, please contact JesseKeating.
- Configure git web and git:// protocols
- Make a get-fedora-package for git
Done!
- Makefile changes for git commands
- Tagging hook to ensure unique tags across an entire <package>
Currently done for cvs with /cvs/extras/CVSROOT/tag-check for CVS.
- ACL framework
- Updated scripts for importing srpms (creating new <packages>)
- Updated scripts for "branching" for a release
- Integration of email notification scripts
- Modify plague to be able to pull an git tag to build from.
- Configure plague to send emails regarding job completion/failure
Gotchas
- git commit doesn't actually commit anything, needs -a
- repo size is huge after conversion, a git repack -a -d is needed
- You must have GIT_COMMITTER_NAME and GIT_AUTHOR_NAME env set, or git must be able to guess based on your username/hostname.
- You can't clone based on a tag, you have to create a temporary branch within a clone to import a tag into... confusing!