On Thu, Oct 6, 2011 at 1:51 PM, Daniel Shahaf <d...@daniel.shahaf.name> wrote:
>> >> 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.
I don't have experience with using git-svn myself, but it seems to be
designed to handle that scenario. However, I think the main value
would be the ability to do more work 'offline' with the commits back
to svn done in batches. If you are trying to coordinate changes
between different teams working on the same project, you'll probably
want frequent commits anyway. If the work is mostly/all being done
at the remote site you could move the live repository there and use an
automated snvsync to keep a local read-only copy as a backup and for
test builds.
--
Les Mikesell
lesmikes...@gmail.com
