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:
> - 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

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).


Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email:   jabber:
twitter: magthe     

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

Attachment: pgpS3R2J7bQ1f.pgp
Description: PGP signature

Reply via email to