On Sun, Jan 02, 2011 at 08:04:14AM -0800, navtis wrote:
> I'm new to git, and am looking for advice on the best way to create a
> moderately complicated setup with the following constraints:
> * The main public repository for this software is subversion, and is
> not under my control
> * I need to fetch updates from the subversion repository to my
> development host (running gentoo) regularly, but cannot write to it
> (my updates are pushed back through manually created patches)
> * I need to create two branches for my local code, both of which need
> to be regularly merged with the updates from subversion
> * I need to be able to export both branches local code to a staging
> server, which is running centos (the OS is relevant as I expect to
> have to make minor tweaks to the code to get it running with different
> library versions etc)
> * The production server is running RHE, and no development work should
> take place on it. It will only run one of the two branches.
> * I am working on my own at the moment but there are likely to be
> other developers involved soon
I'm not quite sure what exactly you want advice on.
If you only need to periodically fetch from a Subversion repo using
git-svn, that's fine -- you will get a branch which is not really
different from a branch that would result from fetching from a Git repo.
The rest is just usual Git operations which will not be aware of
the fact Subversion is present in this picture.
The only problem I can envision off the top of my head is the need to
maintain the "authors" file to do fetches from Subversion and get
sensible author names and e-mail addresses in the generated Git commits.
See  for the hints on how to do this.
Hence, the course of action for you would probably be:
1) Prepare the authors file.
2) git-svn clone the Subversion repo.
3) Fork its master branch to your two local branches.
4) Add another two remotes (the first one will be "svn", created by git-svn)
which you will use to do pushes to your staging and production
5) When needed, `git svn fetch` the changes from the Subversion repo
then switch to each of your local branches in turn and do `git rebase
master` in them.
6) How to push to the staging and production servers is really beyond
this question as it depends on your requirements and taste.
Having multiple developers working with you *might* require that you
have only one box which does fetching from the Subversion repo and then
pushes the resulting changes in the tracking branch to some server, and
everyone else fetches from there. This might be necessary as fetching
from Subversion *creates* Git commit objects, and this process depends
on local settings (including the authors file, if used) -- having
different local settings might result in creation of commits which hash
to different SHA-1 hashes for the same Subversion revisions, and this
obviously breaks the idea central to Git of identical objects having
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at