Hi Dmitry I'm going to give example commands to confirm my understanding of the git-svn workflow you described. Any comments or corrections are welcome. On the local server, get a clone of the repository: srvA# git svn clone http://server.com/repo/proj/trunk proj srvA# cd proj Create a local branch, where developers will push to srvA# git branch integration Now a developer clones the repository on the server, and makes a local branch for developement: dev1# git clone ssh://svrA/path/to/repo dev1# git checkout -b new_featureX (Developer makes some changes and commits to the new_featureX branch) Developer now pushes the changes to the integration branch dev1# git push origin new_featureX:integration The merge master now rebases the changes on to the master branch: srvA# git rebase integration Now push the changes to the upstream subversion server: srvA# git svn dcommit At some stage svn users will commit to the subversion repository, and we will need to pull changes into srvA: srvA# git svn rebase Now the integration branch does not include the changes in master, so rebase the changes to integration: srvA# git rebase master integration Finally the developer needs those changes too, so on his master branch: dev1# git rebase origin Is this the process that you were trying to describe? Any additional steps that need to be added? And how do I make sure that when developers push to the server that it results in a fast-forward merge? Do I do that with commit hooks? Thanks again for the advice. Pico On Mon, Sep 15, 2008 at 9:55 PM, Dmitry Potapov <dpotapov@xxxxxxxxx> wrote: > On Mon, Sep 15, 2008 at 4:50 PM, Pico Geyer <picogeyer@xxxxxxxxx> wrote: >> >> 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. > > I used Git in somewhat similar situation where almost all development > was done in Git mirror of SVN, and then the work was propagated to SVN. > There are some limitations with this approach. The most important is > that SVN does not support merges, so you have to linerialize all history > that you want to commit in SVN. That means that you are going to use git > rebase a lot to rewrite history, which is a PITA. Another problem with > this approach is that the author is not preserved. In SVN, all commits will > look like all changes are done by the person who run "git svn dcommit". > > Yet, despite of all these limitations caused by using SVN as backend, > it was far more pleasant to work with Git than with SVN (you can save > your work in progress, you can easily organize the review process, > and many other features such as "git bisect" or "git log -S" just to > name a few...). > >> >> 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? > > Each user has its own copy of the whole repository and they always > commit to their _local_ branches. Then they can push their changes to > the Git repo on your server, but it is a bad idea to push changes to > a local branch of a non-bare repository especially if that branch is > checked out, because push does not (and should not!) update the working > tree and that leads to the situation where all pushed changes are > looked undo in the working tree of that repository. Therefore, you > will probably have a separately integration branch to which users > will push. Oftentimes, users will have to rebase their work on top the > integration branch to be able to push on it (only fast-forward push > should be allowed). > > The merge master will merge this branch to the local branch assotiated > with subversion (it will be fast-forward, not a real merge) and then > run git svn dcommit to propagate to subversion. > > If there were some conflicting changes in subversion repo, the merge > master will have to resolve them. After that update the merge base > should be updated (using git branch -f) to point out to the top of > the subversion branch. > > If users have some changes that were based on the old integration > branches they will have to rebase them to the new position of the > integration branch. As I said above, git rebase is going to be very > often operation in this workflow. > > NOTE: branches in git differs from what they are in subversion. In > essence, they are no more than pointers to where to add the next > commit. When I learned Git, I found very useful the article called > "Git for computer scientists" to understand basic ideas of how Git > works: http://eagain.net/articles/git-for-computer-scientists/ > >> >> 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." >> Does that mean that one should not push changes to a repository that >> was created with "git svn clone ..."? > > No, what the above description says is that SVN specific information is > not cloned when you clone a repo created by svn. It means that users who > cloned from you will not be able to use git-svn to push their changes in > the original subversion repository. Yet, they can push to your repository > as to any other Git repository. > > Dmitry > -- 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
