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 [1] 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 servers. 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 identical hashes. 1. http://wiki.debian.org/Alioth/Git#ConvertaSVNAliothrepositorytoGit -- 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 git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
