Les Mikesell wrote on Thu, Oct 06, 2011 at 13:25:58 -0500: > On Thu, Oct 6, 2011 at 12:55 PM, Daniel Shahaf <d...@daniel.shahaf.name> > wrote: > > David Weintraub wrote on Thu, Oct 06, 2011 at 12:22:33 -0400: > >> What about using "svngit"? We could have an automated process that > >> pulls data from the Subversion repository in the U.S. and creates a > >> local Git repository in India using "svngit'. This could be done when > >> there's no one in the Indian office. Developers could then checkout > >> and commit their changes to their local Git repository. In the middle > >> of the night, the Git repository could then push its changes to > >> Subversion using "gitsvn" Is this a possibility? > > > > And what do you do when the push step fails due to the Subversion > > repository having changed after the pull? > > I think you are supposed to branch for your local git work, then > 'rebase' the svn copy (equivalent to upate) before merging your branch > and using dcommit to push it back to the svn master. Conceptually it > shouldn't be different than the repository changing compared to an > outstanding modified svn working copy. >
I thought David described a solution that implied machine merging, so I wanted to point out that that Doesn't Always Work. Of course, if a developer does the merging then my concern doesn't apply. > -- > Les Mikesell > lesmikes...@gmail.com
