Re: Help using Git(-svn) for specific use case

[Michael J Gruber <michaeljgruber+gmane@fastmail.fm>]

Pico Geyer venit, vidit, dixit 15.09.2008 14:50:
> Hi all.
> 
> I'd like to start using Git within our company. I'm still trying to
> determine if Git can work in our scenario.
> May be someone can offer some advice.
> Our scenario is as follows:
> We have a handful of developers which work at a branch office. This
> office has a rather slow internet connection.
> At the head office, we are (still) using a Subversion server to host
> our source code.
> At the branch office, we would like to do the following:
> * Fetch the latest code from the subversion server.
> * Push changes that we have made at the remote office back to upstream
> SVN server.
> * Be able to share source code changes locally (at the branch office)
> between developers.
> 
> The solution that I imagined is that we would setup a server (lets
> call it A) at the branch office with a Git repository, that all the
> developers can access.
> Developers would then clone the server repository A, make mods and
> then push changes back to A.
> It would be nice if git users could commit to a subversion branch.
> A merge master would then (as necessary) use svn dcommit to push the
> changes up to the svn server.
> Is this scenario possible?
> 
> From the git-svn man page: "git-clone does not clone branches under
> the refs/remotes/ hierarchy or any git-svn metadata, or config. So
> repositories created and managed with using git-svn should use rsync
> for cloning, if cloning is to be done at all."

That is true if you mean by "clone" a complete copy.

> Does that mean that one should not push changes to a repository that
> was created with "git svn clone ..."?

What matters is which branches you push into.

Your developers don't need to push/commit to svn, only into A, if I
understood correctly. Do they need svn-metadata (besides svn revision
numbers)?
If not then the interaction between A and the developers can be a normal
git workflow between git managed branches, and "git clone" will do fine.

Merge master at A could do the following:
- use git svn to keep the svn (remote) branches at A in sync with the
central subversion server
- push them to proper git branches in A, which get picked up by
developers' " git clone"
- maintain integration branches for integrating the changes coming fro
the developers
- dcommit the svn tracking branches back to the central svn server

Disadvantage:
If changes are dcommitted to svn, synced back with git svn fetch, and
then fetched/pull by the developers their commit will look different
(addition git svn info in the commit message). This is similar to a
workflow where you submit by e-mail and your integrated patches get a
different sha1.

Advantage:
For all developers, everything is just git. Only megre master needs to
know git svn.

Cheers,
Michael