Your email client seems to be set to sending HTML-only, which means my email client wasn't able to display the illustration of the SVN repo properly. I've hopefully guessed correctly in my attempt to adjust it below ;)
On Mon, Sep 02, 2013 at 10:40:55PM -0700, Sascha Egerer wrote: > Hi, > > we are currenlty planning to migrate a big project from SVN to GIT. > The project in rolled out to multiple countries (currently about 15) and each > country is based on the "master" but has slight modifications. It's not > possible to localize everthing. > So our current SVN setup looks like this: > > SVN > - master > - trunk > - branches > - feature-111-foo-bar > - bugfix-222-foo-bar > - hotfix-333-foo-bar > - tags > - 1.0.0 > - 1.1.0 > - 1.1.1 > - 1.2.0 > - 1.2.1 > - de > - trunk > - branches > - trags > - 1.0.0 > - 1.1.0 > - 1.1.1 > - 1.2.1 > - us > - trunk > - branches > - trags > - 1.0.0 > - 1.2.1 > > The workflow is the following: > - Development is completely done in the master repository. > - If a country says "hey version 1.1.0 look good for us. we want to > roll this out in our country" we are merging the tag into the > country repository. After the merge some required changes are also > commited to the trunk. After we have finished the country adjusted a > tag will be created for the country. So there is no real > development in the country based repositories. And we do just merged > the requested tags into the countries. > > The question is now what is the best way to do this in git. > 1. Create a branch for each country in the origin repository - then > merge "master tags" into the country branch and create a "country > tag" > 2. Create a own git repository for each country that is added as > remote - pull origin tags and merge them into the country repo. > then merge the tag and create a tag in the country repo > > What would you suggest? Do you have similar setups? To me it sounds like you are using version control (SVN) for two things: 1. Development (in master/trunk) 2. Release management and distribution (by `svn copy` from master/tags/foo to <country>/tags/foo, followed by an `svn switch` by the country operations). If I've understood this properly then it's easier to find a way to use git. I've personally not seen a similar setup, but I have experienced situations where a VCS was used for more than version control of artefacts (e.g. for release management, deployment, etc). It's not necessarily a bad option, but it's useful to always keep in mind what exactly you are using a tool for. Based on your description above I think you can get away with only a single central git repo that the country-based operations can clone. The country-repos would then base their 'master' on a tag, make a few country-specific changes and commit them. When they want to move to a new release (another tag), they simply move 'master' to the new tag and transplant their local changes (using either `git rebase` or `git cherrypick` as needed). /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus The British have "the perfect temperament to be hackers--technically skilled, slightly disrespectful of authority, and just a touch of criminal behavior". -- Mary Ann Davidson, Oracle's Security Chief
pgpS3R2J7bQ1f.pgp
Description: PGP signature
