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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
