Hello Tad,
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@xxxxxxxxx wrote:
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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