Re: synchronization with Subversion
- From
- Semen Vadishev <semen.vadishev@tmatesoft.com>
- Date
- Aug 27, 2012, 18:42 UTC
- Message-ID
- <503BBF86.5090707@tmatesoft.com>
- In-Reply-To
- <OFD8B086DC.EB0E996E-ON85257A53.00705446-85257A53.00707425@sita.aero>
Hello Tad,
Show 5 quoted lines
> we maintain a "central/main" git repository which our developers clone > from. We want to synchronize this "central" git repository with > Subversion. I know this is not the recommended way to do this, but this > was the choice that was made. The "central" git repository was originally > cloned from Subversion as that was our migration path to git.
Have you looked at SubGit, http://subgit.com/ ?
SubGit is a bi-directional git-svn synchronization tool. It's basically a set of hooks that enable instant conversion of changes between Subversion and Git repositories. So, I think it'd work great for you.
SubGit does not use git-svn internally, it's built on home-grown conversion engine. Most probably you have to re-translate your Subversion repository with SubGit in order to keep repositories synced.
SubGit is a commercial closed-source product. But we provide free options for open-source and academic projects. It's also free for evaluation period.
Semen Vadishev, TMate Software, http://subgit.com/ - git+svn on the server side!
On 8/7/12 22:28, Tad.Mannes@sita.aero wrote:
Show 51 quoted lines
> Greetings, > > we maintain a "central/main" git repository which our developers clone > from. We want to synchronize this "central" git repository with > Subversion. I know this is not the recommended way to do this, but this > was the choice that was made. The "central" git repository was originally > cloned from Subversion as that was our migration path to git. > > Currently I can't get the synchronization to work again after another > sprint. I get the following error message: > Unable to determine upstream SVN information from HEAD history. > Perhaps the repository is empty. at /usr/libexec/git-core/git-svn line > 525. > This synchronization has worked a number of times, but now it always fails > with the above error. > > I have read that it's best to have a linear commit history when > synchronizing to Subversion, and I've read that "git rebase" is the way to > accomplish this. I've attempted this, but I run into two problems trying > to do this: > > 1. Any files/directories which get moved/renamed cause the rebase to stop > and I have to tell git to skip the commit, though it appears to me that > the move/rename actually worked. I am confused by this behavior, and > don't understand why it happens at all. > > 2. There are a number of conflicts which occur during the rebase. This > also confuses me. I think I understand why they happen, but I'm not clear > about how to handle them. Our code base goes back many years and contains > a huge number of commits (originally in CVS, then migrated to Subversion > and Git). It isn't obvious what impact the conflict resolution would > have. My suspicion, is that it will breed even more conflicts as the > rebase continues from that point. > > As you might have guessed, Subversion is the corporate mandated > repository, which is why we are attempting to maintain the > synchronization. We have a "central" git repository as we want to have > more control over which changes are accepted. > > I'm hoping for some suggestions for dealing with this. Any takers? > > Thnks/Brgds --Tad > --- > Tad K. Mannes > Senior Developer > SITA - Societe Internationale de Telecommunications Aeronautiques > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >