GitSuperRepoUnsorted
Revision as of 08:36, 27 June 2011 by Barry.wardell (talk | contribs)
This is a list of things that would be useful to include in the documentation somewhere
- A possible way to link the problems and solutions would be with two or three common scenarios. These would highlight a limitation/annoyance and show how our system provides an easy solution.
- A nice summary: The idea is to have a central "group" repository which points to a series of git and git-svn repositories as submodules, checked out using GetComponents. The group repository is what is cloned by users in the group, and will contain both public and private code. Gitolite can handle permissions based on users and branches. The group repository (and its submodules) would be updated from the upstream versions on any commits, and users could pull from the group repository when they wanted to.
- We could also have branches in the repository for the ET releases, and switching between them should be a lot easier than it is now (which is usually a case of "nuke your tree and check out again").
- We should also provide a public example of such a repository, containing e.g. the Einstein Toolkit. This could then be used in our ET demonstration.
Current setup
- A git repository which only contains submodules and a few symlinks.
- Git submodules for each remote repository.
- In the case where the remote repository is an svn server, there is a git-svn clone hosted by us. Users can create and push new branches to this clone (provided they're named numrel/*), but cannot update the branches which come from svn.
- Similarly for remote Mercurial repositories I have a git clone which we host.
- For remote git repositories where we may want 'internal' branches, we host a mirror of the remote repository and allow additional branches to be created. These additional branches are only on our mirror, they are not pushed back upstream. As an example of this, we have a mirror of McLachlan which has a branch with vectorisation enabled.
- All mirrors (git-svn, git-hg and git) are automatically kept up to date with an hourly cron job, as is the 'submodules' branch of the super-repository.
- Commiting back upstream works for git, svn and hg.
