{"thread":{"id":"31203","subject":"synchronization with Subversion","startedAt":"2012-08-07T20:28:17Z","lastAt":"2012-08-27T18:42:14Z","messageCount":2,"participants":["tad.mannes@sita.aero","Semen Vadishev"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"196620","messageId":"OFD8B086DC.EB0E996E-ON85257A53.00705446-85257A53.00707425@sita.aero","threadId":"31203","inReplyTo":null,"subject":"synchronization with Subversion","fromName":"","fromEmail":"tad.mannes@sita.aero","sentAt":"2012-08-07T20:28:17Z","receivedAt":"2012-08-07T20:28:17Z","isPatch":false,"sender":{"key":"tad.mannes@sita.aero","avatar":null},"body":"Greetings,\n\nwe maintain a \"central/main\" git repository which our developers clone \nfrom.  We want to synchronize this \"central\" git repository with \nSubversion.  I know this is not the recommended way to do this, but this \nwas the choice that was made.  The \"central\" git repository was originally \ncloned from Subversion as that was our migration path to git.\n\nCurrently I can't get the synchronization to work again after another \nsprint.  I get the following error message:\nUnable to determine upstream SVN information from HEAD history.\nPerhaps the repository is empty. at /usr/libexec/git-core/git-svn line \n525.\nThis synchronization has worked a number of times, but now it always fails \nwith the above error.\n\nI have read that it's best to have a linear commit history when \nsynchronizing to Subversion, and I've read that \"git rebase\" is the way to \naccomplish this.  I've attempted this, but I run into two problems trying \nto do this:\n\n1. Any files/directories which get moved/renamed cause the rebase to stop \nand I have to tell git to skip the commit, though it appears to me that \nthe move/rename actually worked.  I am confused by this behavior, and \ndon't understand why it happens at all.\n\n2. There are a number of conflicts which occur during the rebase.  This \nalso confuses me.  I think I understand why they happen, but I'm not clear \nabout how to handle them.  Our code base goes back many years and contains \na huge number of commits (originally in CVS, then migrated to Subversion \nand Git).  It isn't obvious what impact the conflict resolution would \nhave.  My suspicion, is that it will breed even more conflicts as the \nrebase continues from that point.\n\nAs you might have guessed, Subversion is the corporate mandated \nrepository, which is why we are attempting to maintain the \nsynchronization.  We have a \"central\" git repository as we want to have \nmore control over which changes are accepted.\n\nI'm hoping for some suggestions for dealing with this.  Any takers?\n\nThnks/Brgds             --Tad\n--- \nTad K. Mannes\nSenior Developer\nSITA - Societe Internationale de Telecommunications Aeronautiques\n"},{"id":"197927","messageId":"503BBF86.5090707@tmatesoft.com","threadId":"31203","inReplyTo":"OFD8B086DC.EB0E996E-ON85257A53.00705446-85257A53.00707425@sita.aero","subject":"Re: synchronization with Subversion","fromName":"Semen Vadishev","fromEmail":"semen.vadishev@tmatesoft.com","sentAt":"2012-08-27T18:42:14Z","receivedAt":"2012-08-27T18:42:14Z","isPatch":false,"sender":{"key":"semen.vadishev@tmatesoft.com","avatar":null},"body":"Hello Tad,\n\n> we maintain a \"central/main\" git repository which our developers clone\n> from.  We want to synchronize this \"central\" git repository with\n> Subversion.  I know this is not the recommended way to do this, but this\n> was the choice that was made.  The \"central\" git repository was originally\n> cloned from Subversion as that was our migration path to git.\n\nHave you looked at SubGit, http://subgit.com/ ?\n\nSubGit is a bi-directional git-svn synchronization tool. It's basically \na set of hooks that enable instant conversion of changes between \nSubversion and Git repositories. So, I think it'd work great for you.\n\nSubGit does not use git-svn internally, it's built on home-grown \nconversion engine. Most probably you have to re-translate your \nSubversion repository with SubGit in order to keep repositories synced.\n\nSubGit is a commercial closed-source product. But we provide free \noptions for open-source and academic projects. It's also free for \nevaluation period.\n\nSemen Vadishev,\nTMate Software,\nhttp://subgit.com/ - git+svn on the server side!\n\nOn 8/7/12 22:28, Tad.Mannes@sita.aero wrote:\n> Greetings,\n>\n> we maintain a \"central/main\" git repository which our developers clone\n> from.  We want to synchronize this \"central\" git repository with\n> Subversion.  I know this is not the recommended way to do this, but this\n> was the choice that was made.  The \"central\" git repository was originally\n> cloned from Subversion as that was our migration path to git.\n>\n> Currently I can't get the synchronization to work again after another\n> sprint.  I get the following error message:\n> Unable to determine upstream SVN information from HEAD history.\n> Perhaps the repository is empty. at /usr/libexec/git-core/git-svn line\n> 525.\n> This synchronization has worked a number of times, but now it always fails\n> with the above error.\n>\n> I have read that it's best to have a linear commit history when\n> synchronizing to Subversion, and I've read that \"git rebase\" is the way to\n> accomplish this.  I've attempted this, but I run into two problems trying\n> to do this:\n>\n> 1. Any files/directories which get moved/renamed cause the rebase to stop\n> and I have to tell git to skip the commit, though it appears to me that\n> the move/rename actually worked.  I am confused by this behavior, and\n> don't understand why it happens at all.\n>\n> 2. There are a number of conflicts which occur during the rebase.  This\n> also confuses me.  I think I understand why they happen, but I'm not clear\n> about how to handle them.  Our code base goes back many years and contains\n> a huge number of commits (originally in CVS, then migrated to Subversion\n> and Git).  It isn't obvious what impact the conflict resolution would\n> have.  My suspicion, is that it will breed even more conflicts as the\n> rebase continues from that point.\n>\n> As you might have guessed, Subversion is the corporate mandated\n> repository, which is why we are attempting to maintain the\n> synchronization.  We have a \"central\" git repository as we want to have\n> more control over which changes are accepted.\n>\n> I'm hoping for some suggestions for dealing with this.  Any takers?\n>\n> Thnks/Brgds             --Tad\n> ---\n> Tad K. Mannes\n> Senior Developer\n> SITA - Societe Internationale de Telecommunications Aeronautiques\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"}]}