{"thread":{"id":"24133","subject":"SVN migration","startedAt":"2010-06-16T23:02:07Z","lastAt":"2010-07-04T22:01:30Z","messageCount":10,"participants":["William Hall","Steven Michalske","Joshua Shrader","David Bainbridge"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"143838","messageId":"4C1957EF.6070504@gnatter.net","threadId":"24133","inReplyTo":null,"subject":"SVN migration","fromName":"William Hall","fromEmail":"will@gnatter.net","sentAt":"2010-06-16T23:02:07Z","receivedAt":"2010-06-16T23:02:07Z","isPatch":false,"sender":{"key":"will@gnatter.net","avatar":null},"body":"Hi gitters,\n\nBackground - I'm trying to convince my company to ditch SVN for git - \nthe usual story. So for the duration of a project I'll be running git \nand SVN in parallel - the idea being is that we will still commit to SVN \n(and update), but the development work internal to my team will be using \ngit.\n\nAn absolute *must* is for the SVN repo to continue as the SCM authority \n- at least until I can persuade the company to switch to git permanently.\n\nHere's some crap ascii art to show the situation,\n\n--------------\n| non-git dev |\n--------------\n      |\n      |\n   -------         ----------------\n  |  SVN  |-------| git/SVN bridge |\n   -------         ----------------\n                         |\n                   ---------------\n                  | bare git Repo |\n                   ---------------\n                         |\n          ------------------------------\n          |              |              |\n        dev_1          dev_2          dev 3\n\n\n- the git/SVN bridge is a git repo created with git-svn-clone.\n\n- the 'bare git' repo is a typical standard git repo and I'm keen for \nthe developers to experience a 'normal' git environment and not have to \nworry about SVN interactions.\n\nAm sure this problem has been considered many times before, but I cannot \nseem to find an effective solution.\n\nThe issue is the dcommit operation from the bridge. The rebase part of \nthis re-writes the commit messages to include the SVN commit-ids which \nis nice, but screws up the push/pulls between the bridge and the bare repo.\n\nOne solution I've tried is to create a branch in the bridge that tracks \nthe bare repo, and another branch to track the SVN server. If the \nbranches are kept separate then I can git-cherry-pick to replay changes \nfrom one side to the other (or at least merge one-way). his is not ideal \nas I really should use git's merge facility. I'd like to guarantee that \nthe sides are not diverging over time.\n\nActually I've tried all permutations of merges/rebases/update-ref, I \nalways fall into the same trap that befits a rebase in conjunction with \nremote repositories.\n\nI can live without tags and branches for the time being - I just want to \nget a robust workflow defined in the bridge for the SVN 'trunk' - ie \nread/writes in both directions.\n\nIf anyone can offer any advice then it would be hugely appreciated. \nPerhaps you'll say that it cannot be done, which would make the git sell \nmuch harder.\n\nHopefully by the end of this exercise git will have 800 more fans.\n\nMany thanks\n\nWill\n"},{"id":"143840","messageId":"7B0F34CE-9C9F-4FC3-AD96-8B1B8DD4359B@gmail.com","threadId":"24133","inReplyTo":"4C1957EF.6070504@gnatter.net","subject":"Re: SVN migration","fromName":"Steven Michalske","fromEmail":"smichalske@gmail.com","sentAt":"2010-06-17T00:41:49Z","receivedAt":"2010-06-17T00:41:49Z","isPatch":false,"sender":{"key":"smichalske@gmail.com","avatar":"https://gravatar.com/avatar/721f27456adc9ac84f3bb235f021a70015abb9e09222ae8622fc5579c6a203c1?d=mp&s=160"},"body":"\nOn Jun 16, 2010, at 4:02 PM, William Hall wrote:\n\n> \n> The issue is the dcommit operation from the bridge. The rebase part of this re-writes the commit messages to include the SVN commit-ids which is nice, but screws up the push/pulls between the bridge and the bare repo.\n\nLook into svn.noMetadata configuration option.  It will prevent you from rebuilding the svn to git bridge if something seriously goes wrong, but it prevents the messages from changing.\n\nsvn-remote.<name>.noMetadata\nThis gets rid of the git-svn-id: lines at the end of every commit.\nIf you lose your .git/svn/git-svn/.rev_db file, git svn will not be able to rebuild it and you won't be able to fetch again, either. This is fine for one-shot imports.\nThe git svn log command will not work on repositories using this, either. Using this conflicts with the useSvmProps option for (hopefully) obvious reasons\n"},{"id":"143855","messageId":"4C19FA07.9010603@gnatter.net","threadId":"24133","inReplyTo":"7B0F34CE-9C9F-4FC3-AD96-8B1B8DD4359B@gmail.com","subject":"Re: SVN migration","fromName":"William Hall","fromEmail":"will@gnatter.net","sentAt":"2010-06-17T10:33:43Z","receivedAt":"2010-06-17T10:33:43Z","isPatch":false,"sender":{"key":"will@gnatter.net","avatar":null},"body":"Thanks Steven,\n\nThe noMetadata option will prevent me from doing anything other than a \none-shot import, which is not what I want. I need to somehow devise a \nworkflow that allows me bidirectional push/pull between an svn repo and \na remote git repo.\n\n\n\nSteven Michalske wrote:\n> On Jun 16, 2010, at 4:02 PM, William Hall wrote:\n> \n>> The issue is the dcommit operation from the bridge. The rebase part of this re-writes the commit messages to include the SVN commit-ids which is nice, but screws up the push/pulls between the bridge and the bare repo.\n> \n> Look into svn.noMetadata configuration option.  It will prevent you from rebuilding the svn to git bridge if something seriously goes wrong, but it prevents the messages from changing.\n> \n> svn-remote.<name>.noMetadata\n> This gets rid of the git-svn-id: lines at the end of every commit.\n> If you lose your .git/svn/git-svn/.rev_db file, git svn will not be able to rebuild it and you won't be able to fetch again, either. This is fine for one-shot imports.\n> The git svn log command will not work on repositories using this, either. Using this conflicts with the useSvmProps option for (hopefully) obvious reasons\n"},{"id":"143878","messageId":"4C1A4CF6.9080300@gnatter.net","threadId":"24133","inReplyTo":"4C19FA07.9010603@gnatter.net","subject":"Re: SVN migration","fromName":"William Hall","fromEmail":"will@gnatter.net","sentAt":"2010-06-17T16:27:34Z","receivedAt":"2010-06-17T16:27:34Z","isPatch":false,"sender":{"key":"will@gnatter.net","avatar":null},"body":"I'm going to answer my own post, I *think* I have something that works - \nplease check if I'm doing anything idiotic.\n\nJust to recap: trying to convince my company to move from svn to git, \nand they have agreed to try one project using git as long as all commits \nfind their way to the svn repo as well.\n\nSo I have a standard bare git repo serving the developers, a git/svn \n\"bridge\" repo that performs bi-directional updates to and from svn and \nthe bare git repo.\n\nOk, here's what I've done\n\nCreate bridge\n-------------\n$ git svn init -s file:///path_to_svn /path_to_git_svn_bridge/\n$ cd /path_to_git_svn_bridge\n$ git svn fetch --authors-file=/tmp/authors.map\n\nConfigure bare repo\n-------------------------------\ncreate bare repo that developers will use\n$ git init --shared=all --bare /path_to_git_repo.git\n\nconfigure bridge\n----------------\n$ git remote add -f -m master origin /path_to_git_repo.git\n$ git push origin master\n$ git branch --set-upstream master origin/master\n\nthis branch will be used to perform svn rebases and fetches\n$ git checkout -t -b svn svn/trunk\n\n\nWorkflow\n--------\nDeveloper A clones from /path_to_git_repo.git, does some work, commits \nand pushes back to origin\n\nNow, in the bridge repo, fetch changes from origin (where developer A \npushed)\n$ git checkout master\n$ git pull\n\nReplay all changes manually, in order, onto svn branch\n$ git checkout svn\n$ git rev-list --reverse heads/master@{1}..heads/master | while read rev; do\n         git cherry-pick -n $rev\n   done\n\nCreate one commit for all changes and synchronise with svn\n$ git commit -am \"cherry pick merge\"\n$ git svn rebase\n$ git svn dcommit\n\nNow merge in anything picked up from svn, plus the rebased final commit\n$ git checkout master\n$ git merge svn\n\nSend back to bare repo (at least the final merge commit)\n$ git push\n\nIt seems to handle changes and preserves linear history on both sides ok.\nCan anyone see anything obviously wrong with this approach?\n\nthanks,\n\nWill\n\n\n\n\n\n\nWilliam Hall wrote:\n > Thanks Steven,\n >\n > The noMetadata option will prevent me from doing anything other than \na one-shot import, which is not what I want. I need to somehow devise a \nworkflow that allows me bidirectional push/pull between an svn repo and \na remote git repo.\n >\n >\n >\n > Steven Michalske wrote:\n >> On Jun 16, 2010, at 4:02 PM, William Hall wrote:\n >>\n >>> The issue is the dcommit operation from the bridge. The rebase part \nof this re-writes the commit messages to include the SVN commit-ids \nwhich is nice, but screws up the push/pulls between the bridge and the \nbare repo.\n >>\n >> Look into svn.noMetadata configuration option.  It will prevent you \nfrom rebuilding the svn to git bridge if something seriously goes wrong, \nbut it prevents the messages from changing.\n >>\n >> svn-remote.<name>.noMetadata\n >> This gets rid of the git-svn-id: lines at the end of every commit.\n >> If you lose your .git/svn/git-svn/.rev_db file, git svn will not be \nable to rebuild it and you won't be able to fetch again, either. This is \nfine for one-shot imports.\n >> The git svn log command will not work on repositories using this, \neither. Using this conflicts with the useSvmProps option for (hopefully) \nobvious reasons\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\nWilliam Hall wrote:\n> Thanks Steven,\n> \n> The noMetadata option will prevent me from doing anything other than a \n> one-shot import, which is not what I want. I need to somehow devise a \n> workflow that allows me bidirectional push/pull between an svn repo and \n> a remote git repo.\n> \n> \n> \n> Steven Michalske wrote:\n>> On Jun 16, 2010, at 4:02 PM, William Hall wrote:\n>>\n>>> The issue is the dcommit operation from the bridge. The rebase part \n>>> of this re-writes the commit messages to include the SVN commit-ids \n>>> which is nice, but screws up the push/pulls between the bridge and \n>>> the bare repo.\n>>\n>> Look into svn.noMetadata configuration option.  It will prevent you \n>> from rebuilding the svn to git bridge if something seriously goes \n>> wrong, but it prevents the messages from changing.\n>>\n>> svn-remote.<name>.noMetadata\n>> This gets rid of the git-svn-id: lines at the end of every commit.\n>> If you lose your .git/svn/git-svn/.rev_db file, git svn will not be \n>> able to rebuild it and you won't be able to fetch again, either. This \n>> is fine for one-shot imports.\n>> The git svn log command will not work on repositories using this, \n>> either. Using this conflicts with the useSvmProps option for \n>> (hopefully) obvious reasons\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"},{"id":"143999","messageId":"AANLkTinUc5z66Yk13ZKgHU113nRuAcl3HyC3eXAJAE6j@mail.gmail.com","threadId":"24133","inReplyTo":"4C1A4CF6.9080300@gnatter.net","subject":"Re: SVN migration","fromName":"Joshua Shrader","fromEmail":"jshrader83@gmail.com","sentAt":"2010-06-21T21:12:24Z","receivedAt":"2010-06-21T21:12:24Z","isPatch":false,"sender":{"key":"jshrader83@gmail.com","avatar":null},"body":"In Jon Loeliger's \"Version Control with Git\", Chapter 16, he describes\na similar situation in which there is a Subversion repository, and at\nleast a couple users that want to be using Git.  He proposes a single\n\"gatekeeper\" git repository, what you refer to as a bridge, which is\nthe only interface to subversion.  After git svn cloneing the\nsubversion repo (with --prefix=svn/), all the branches are then pushed\nto a bare repository (git push ../svn-bare.git\n'refs/remotes/svn/*:refs/heads/svn/*', and other git users are told to\nclone this repo, which now contains local branches of all the svn\nremotes.  Then, to merge back to subversion, in the gatekeeper repo,\nyou do\n\ngit checkout svn/trunk (or other branch - this is checking out a\ndetached head as svn/trunk is a remote)\ngit merge --no-ff new-feature\ngit svn dcommit\n\nThis results in a merge commit on a detached head, and then the\nmodified commit (after the git-svn-id line is added) is put on the\nreal svn/trunk branch.  The commit on the detached head is \"worse than\nredundant.  Using it for anything else eventually results in\nconflicts.  So, just forget about that commit.  If you haven't put it\non a branch in the first place, it's that much easier to forget\" (Jon\nLoeliger).\n\nI haven't tried this yet, but I'm in a similar situation in that I'm\ntrying to convince my project to convert to using Git.  We're going to\nuse this gatekeeper approach for a while, and allow users to migrate\nover at their own discretion.  Then hopefully, if there's not too much\nresistance, we'll get rid of the subversion repo entirely.\n\nIf there's a problem with this workflow, I'd love to hear about it.\nI'm only in the middle of setting this up, but hopefully I should know\nif it works by the end of the week.\n\nOn Thu, Jun 17, 2010 at 12:27 PM, William Hall <will@gnatter.net> wrote:\n> I'm going to answer my own post, I *think* I have something that works -\n> please check if I'm doing anything idiotic.\n>\n> Just to recap: trying to convince my company to move from svn to git, and\n> they have agreed to try one project using git as long as all commits find\n> their way to the svn repo as well.\n>\n> So I have a standard bare git repo serving the developers, a git/svn\n> \"bridge\" repo that performs bi-directional updates to and from svn and the\n> bare git repo.\n>\n> Ok, here's what I've done\n>\n> Create bridge\n> -------------\n> $ git svn init -s file:///path_to_svn /path_to_git_svn_bridge/\n> $ cd /path_to_git_svn_bridge\n> $ git svn fetch --authors-file=/tmp/authors.map\n>\n> Configure bare repo\n> -------------------------------\n> create bare repo that developers will use\n> $ git init --shared=all --bare /path_to_git_repo.git\n>\n> configure bridge\n> ----------------\n> $ git remote add -f -m master origin /path_to_git_repo.git\n> $ git push origin master\n> $ git branch --set-upstream master origin/master\n>\n> this branch will be used to perform svn rebases and fetches\n> $ git checkout -t -b svn svn/trunk\n>\n>\n> Workflow\n> --------\n> Developer A clones from /path_to_git_repo.git, does some work, commits and\n> pushes back to origin\n>\n> Now, in the bridge repo, fetch changes from origin (where developer A\n> pushed)\n> $ git checkout master\n> $ git pull\n>\n> Replay all changes manually, in order, onto svn branch\n> $ git checkout svn\n> $ git rev-list --reverse heads/master@{1}..heads/master | while read rev; do\n>        git cherry-pick -n $rev\n>  done\n>\n> Create one commit for all changes and synchronise with svn\n> $ git commit -am \"cherry pick merge\"\n> $ git svn rebase\n> $ git svn dcommit\n>\n> Now merge in anything picked up from svn, plus the rebased final commit\n> $ git checkout master\n> $ git merge svn\n>\n> Send back to bare repo (at least the final merge commit)\n> $ git push\n>\n> It seems to handle changes and preserves linear history on both sides ok.\n> Can anyone see anything obviously wrong with this approach?\n>\n> thanks,\n>\n> Will\n>\n>\n>\n>\n>\n>\n> William Hall wrote:\n>> Thanks Steven,\n>>\n>> The noMetadata option will prevent me from doing anything other than a\n>> one-shot import, which is not what I want. I need to somehow devise a\n>> workflow that allows me bidirectional push/pull between an svn repo and a\n>> remote git repo.\n>>\n>>\n>>\n>> Steven Michalske wrote:\n>>> On Jun 16, 2010, at 4:02 PM, William Hall wrote:\n>>>\n>>>> The issue is the dcommit operation from the bridge. The rebase part of\n>>>> this re-writes the commit messages to include the SVN commit-ids which is\n>>>> nice, but screws up the push/pulls between the bridge and the bare repo.\n>>>\n>>> Look into svn.noMetadata configuration option.  It will prevent you from\n>>> rebuilding the svn to git bridge if something seriously goes wrong, but it\n>>> prevents the messages from changing.\n>>>\n>>> svn-remote.<name>.noMetadata\n>>> This gets rid of the git-svn-id: lines at the end of every commit.\n>>> If you lose your .git/svn/git-svn/.rev_db file, git svn will not be able\n>>> to rebuild it and you won't be able to fetch again, either. This is fine for\n>>> one-shot imports.\n>>> The git svn log command will not work on repositories using this, either.\n>>> Using this conflicts with the useSvmProps option for (hopefully) obvious\n>>> reasons\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>\n> William Hall wrote:\n>>\n>> Thanks Steven,\n>>\n>> The noMetadata option will prevent me from doing anything other than a\n>> one-shot import, which is not what I want. I need to somehow devise a\n>> workflow that allows me bidirectional push/pull between an svn repo and a\n>> remote git repo.\n>>\n>>\n>>\n>> Steven Michalske wrote:\n>>>\n>>> On Jun 16, 2010, at 4:02 PM, William Hall wrote:\n>>>\n>>>> The issue is the dcommit operation from the bridge. The rebase part of\n>>>> this re-writes the commit messages to include the SVN commit-ids which is\n>>>> nice, but screws up the push/pulls between the bridge and the bare repo.\n>>>\n>>> Look into svn.noMetadata configuration option.  It will prevent you from\n>>> rebuilding the svn to git bridge if something seriously goes wrong, but it\n>>> prevents the messages from changing.\n>>>\n>>> svn-remote.<name>.noMetadata\n>>> This gets rid of the git-svn-id: lines at the end of every commit.\n>>> If you lose your .git/svn/git-svn/.rev_db file, git svn will not be able\n>>> to rebuild it and you won't be able to fetch again, either. This is fine for\n>>> one-shot imports.\n>>> The git svn log command will not work on repositories using this, either.\n>>> Using this conflicts with the useSvmProps option for (hopefully) obvious\n>>> reasons\n>>\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> --\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"},{"id":"144014","messageId":"4C1FE714.6080100@gnatter.net","threadId":"24133","inReplyTo":"AANLkTinUc5z66Yk13ZKgHU113nRuAcl3HyC3eXAJAE6j@mail.gmail.com","subject":"Re: SVN migration","fromName":"William Hall","fromEmail":"will@gnatter.net","sentAt":"2010-06-21T22:26:28Z","receivedAt":"2010-06-21T22:26:28Z","isPatch":false,"sender":{"key":"will@gnatter.net","avatar":null},"body":"Hi Joshua - glad I'm not the only one facing this conundrum.\n\nYes, I've followed the Jon Loeliger's guide and am using something very \nsimilar.\n\nI've come up with a couple of solutions, but this is my latest effort.\nThe only real difference in our situations is that I wanted the \ndevelopers to get a feel of a bog-standard bare git repo to which they \npull/push as usual - the gateway (...much better name) will also push \nand pull to this.\n\nI've created a post-update hook in the bare git repo that does the \nfollowing on the gateway repo\n\n( there's a branch \"svn\" that tracks refs/remotes/svn/trunk)\n- pulls commits from bare repo into master (all current dev work)\n- on svn branch, run \"git merge --squash master\"\n- commit changes\n- git svn rebase (pick up changes from other depts)\n- git svn dcommit\n- switch back to master and merge in svn changes (with --no-ff)\n- git push, back to bare repo\n\nAll git commits between pushes are squashed which probably represents \nthe frequency of usual svn commits (ie, only when something is finished) \nso it's probably ok. Also, it prevents the developers from seeing \nduplicate commit messages - one from master and a duplicate (with svn \ncommit-id) which may get annoying or confusing.\n\nI've also tried doing a rebase with --onto to replay all changes to \nmaster onto the svn branch, which is ok, but all commits are duplicated \nand propagated.\n\nI'm keen to merge the branches at some stage otherwise I'll end up with \ntwo branches on the gateway that never converge - which is probably not \na good idea.\n\nHave tried (briefly) your solution which also seems to work, but without \nany merge commits - will try more.\n\nNaturally, I'd like a completely linear history, but the does not seem \nviable. I don't think git will be hard sell (most of our developers seem \nto agree that git is the future), but I need to get this right from the \noutset or confidence will be lost.\n\n\nwill\n\n\n\n\nOn 21/06/10 22:12, Joshua Shrader wrote:\n> In Jon Loeliger's \"Version Control with Git\", Chapter 16, he describes\n> a similar situation in which there is a Subversion repository, and at\n> least a couple users that want to be using Git.  He proposes a single\n> \"gatekeeper\" git repository, what you refer to as a bridge, which is\n> the only interface to subversion.  After git svn cloneing the\n> subversion repo (with --prefix=svn/), all the branches are then pushed\n> to a bare repository (git push ../svn-bare.git\n> 'refs/remotes/svn/*:refs/heads/svn/*', and other git users are told to\n> clone this repo, which now contains local branches of all the svn\n> remotes.  Then, to merge back to subversion, in the gatekeeper repo,\n> you do\n>\n> git checkout svn/trunk (or other branch - this is checking out a\n> detached head as svn/trunk is a remote)\n> git merge --no-ff new-feature\n> git svn dcommit\n>\n> This results in a merge commit on a detached head, and then the\n> modified commit (after the git-svn-id line is added) is put on the\n> real svn/trunk branch.  The commit on the detached head is \"worse than\n> redundant.  Using it for anything else eventually results in\n> conflicts.  So, just forget about that commit.  If you haven't put it\n> on a branch in the first place, it's that much easier to forget\" (Jon\n> Loeliger).\n>\n> I haven't tried this yet, but I'm in a similar situation in that I'm\n> trying to convince my project to convert to using Git.  We're going to\n> use this gatekeeper approach for a while, and allow users to migrate\n> over at their own discretion.  Then hopefully, if there's not too much\n> resistance, we'll get rid of the subversion repo entirely.\n>\n> If there's a problem with this workflow, I'd love to hear about it.\n> I'm only in the middle of setting this up, but hopefully I should know\n> if it works by the end of the week.\n>\n> On Thu, Jun 17, 2010 at 12:27 PM, William Hall<will@gnatter.net>  wrote:\n>> I'm going to answer my own post, I *think* I have something that works -\n>> please check if I'm doing anything idiotic.\n>>\n>> Just to recap: trying to convince my company to move from svn to git, and\n>> they have agreed to try one project using git as long as all commits find\n>> their way to the svn repo as well.\n>>\n>> So I have a standard bare git repo serving the developers, a git/svn\n>> \"bridge\" repo that performs bi-directional updates to and from svn and the\n>> bare git repo.\n>>\n>> Ok, here's what I've done\n>>\n>> Create bridge\n>> -------------\n>> $ git svn init -s file:///path_to_svn /path_to_git_svn_bridge/\n>> $ cd /path_to_git_svn_bridge\n>> $ git svn fetch --authors-file=/tmp/authors.map\n>>\n>> Configure bare repo\n>> -------------------------------\n>> create bare repo that developers will use\n>> $ git init --shared=all --bare /path_to_git_repo.git\n>>\n>> configure bridge\n>> ----------------\n>> $ git remote add -f -m master origin /path_to_git_repo.git\n>> $ git push origin master\n>> $ git branch --set-upstream master origin/master\n>>\n>> this branch will be used to perform svn rebases and fetches\n>> $ git checkout -t -b svn svn/trunk\n>>\n>>\n>> Workflow\n>> --------\n>> Developer A clones from /path_to_git_repo.git, does some work, commits and\n>> pushes back to origin\n>>\n>> Now, in the bridge repo, fetch changes from origin (where developer A\n>> pushed)\n>> $ git checkout master\n>> $ git pull\n>>\n>> Replay all changes manually, in order, onto svn branch\n>> $ git checkout svn\n>> $ git rev-list --reverse heads/master@{1}..heads/master | while read rev; do\n>>         git cherry-pick -n $rev\n>>   done\n>>\n>> Create one commit for all changes and synchronise with svn\n>> $ git commit -am \"cherry pick merge\"\n>> $ git svn rebase\n>> $ git svn dcommit\n>>\n>> Now merge in anything picked up from svn, plus the rebased final commit\n>> $ git checkout master\n>> $ git merge svn\n>>\n>> Send back to bare repo (at least the final merge commit)\n>> $ git push\n>>\n>> It seems to handle changes and preserves linear history on both sides ok.\n>> Can anyone see anything obviously wrong with this approach?\n>>\n>> thanks,\n>>\n>> Will\n>>\n>>\n>>\n>>\n>>\n>>\n>> William Hall wrote:\n>>> Thanks Steven,\n>>>\n>>> The noMetadata option will prevent me from doing anything other than a\n>>> one-shot import, which is not what I want. I need to somehow devise a\n>>> workflow that allows me bidirectional push/pull between an svn repo and a\n>>> remote git repo.\n>>>\n>>>\n>>>\n>>> Steven Michalske wrote:\n>>>> On Jun 16, 2010, at 4:02 PM, William Hall wrote:\n>>>>\n>>>>> The issue is the dcommit operation from the bridge. The rebase part of\n>>>>> this re-writes the commit messages to include the SVN commit-ids which is\n>>>>> nice, but screws up the push/pulls between the bridge and the bare repo.\n>>>>\n>>>> Look into svn.noMetadata configuration option.  It will prevent you from\n>>>> rebuilding the svn to git bridge if something seriously goes wrong, but it\n>>>> prevents the messages from changing.\n>>>>\n>>>> svn-remote.<name>.noMetadata\n>>>> This gets rid of the git-svn-id: lines at the end of every commit.\n>>>> If you lose your .git/svn/git-svn/.rev_db file, git svn will not be able\n>>>> to rebuild it and you won't be able to fetch again, either. This is fine for\n>>>> one-shot imports.\n>>>> The git svn log command will not work on repositories using this, either.\n>>>> Using this conflicts with the useSvmProps option for (hopefully) obvious\n>>>> reasons\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>>\n>> William Hall wrote:\n>>>\n>>> Thanks Steven,\n>>>\n>>> The noMetadata option will prevent me from doing anything other than a\n>>> one-shot import, which is not what I want. I need to somehow devise a\n>>> workflow that allows me bidirectional push/pull between an svn repo and a\n>>> remote git repo.\n>>>\n>>>\n>>>\n>>> Steven Michalske wrote:\n>>>>\n>>>> On Jun 16, 2010, at 4:02 PM, William Hall wrote:\n>>>>\n>>>>> The issue is the dcommit operation from the bridge. The rebase part of\n>>>>> this re-writes the commit messages to include the SVN commit-ids which is\n>>>>> nice, but screws up the push/pulls between the bridge and the bare repo.\n>>>>\n>>>> Look into svn.noMetadata configuration option.  It will prevent you from\n>>>> rebuilding the svn to git bridge if something seriously goes wrong, but it\n>>>> prevents the messages from changing.\n>>>>\n>>>> svn-remote.<name>.noMetadata\n>>>> This gets rid of the git-svn-id: lines at the end of every commit.\n>>>> If you lose your .git/svn/git-svn/.rev_db file, git svn will not be able\n>>>> to rebuild it and you won't be able to fetch again, either. This is fine for\n>>>> one-shot imports.\n>>>> The git svn log command will not work on repositories using this, either.\n>>>> Using this conflicts with the useSvmProps option for (hopefully) obvious\n>>>> reasons\n>>>\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>> --\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"},{"id":"144295","messageId":"4C25D783.4070602@gnatter.net","threadId":"24133","inReplyTo":"4C1957EF.6070504@gnatter.net","subject":"Re: SVN migration","fromName":"William Hall","fromEmail":"will@gnatter.net","sentAt":"2010-06-26T10:33:39Z","receivedAt":"2010-06-26T10:33:39Z","isPatch":false,"sender":{"key":"will@gnatter.net","avatar":null},"body":"http://github.com/innerhippy/svnAndGit\n\nI've created a new project on github called svnAndGit that attempts to \ncreate a bi-directional workflow to enable git and SVN to live side-by-side.\n\nIt's not perfect by any means, so all comments most welcome!\n"},{"id":"144742","messageId":"AANLkTimtGoNQe2-nA_Qn_qsZP2Iley9x6TU3Ht28Eg4t@mail.gmail.com","threadId":"24133","inReplyTo":"4C25D783.4070602@gnatter.net","subject":"Re: SVN migration","fromName":"David Bainbridge","fromEmail":"david.bainbridge@gmail.com","sentAt":"2010-07-03T11:37:57Z","receivedAt":"2010-07-03T11:37:57Z","isPatch":false,"sender":{"key":"david.bainbridge@gmail.com","avatar":"https://gravatar.com/avatar/1689d4383c7d0d399e2803ddbbecf83b7a4cb9bff89f45917e28b351933ccef1?d=mp&s=160"},"body":"Hi William,\n\nI have been following this thread with interest so I thought that I\nwould just throw in my thoughts!\n\nWhile maintaining synchronization with Git is part of what is needed I\nsuspect that this will not entirely convince the management of your\ncompany that Git is the way forward.\n\nThey probably see Svn as a safe repository ... The company's assets\n(intellectual property) are on a central server that is backed up, and\nthe contents of that repository can be audited and so on. They may be\nthinking about things like SOX compliance too.\n\nSo if you want them to accept Git as a replacement for svn then you\nneed to understand and address these concerns. This means that you\nwill have to have a conversation with them. To a large extent this a\npeople thing ... technical solutions won't necessary convince them.\nThey are running a company based on the knowledge and information they\nown - and they want to make sure that it doesn't get lost, stolen,\ncorrupted, or whatever. And they are accountable to the shareholders\nfor this.\n\nAlso, you say that they have been using Svn for donkey's years, so\nfrom a corporate perspective it probably does what they want and need.\nOtherwise THEY would have decided to change it.\n\nI am in a similar situation and while developers clearly want to use\ngIt, the motivation from a corporate perspective is less clear and can\nbe perceived as introducing risk. So we are looking at the wya in\nwhich repositories are set up, the topology of git repository\nnetworks, use of Gitosis. Gitolite and Gitorious, and so on, to\nprovide some security in the corporate environment.\n\nEvery company will have a different view of this so there is no\n'right' answer. A lot depends on the type of product you produce and\nhow long it will need to be supported. If you have products that need\nto be supported for 10 years or more then promoting a tool that is 5\nyears old may also raise some eyebrows! You need to have the answers\nready :-)\n\nGet it right and you will be seen as a hero who understands the\nbusiness. Get it wrong and you will consigned to the religious nerd\ncategory who just wants to promote his favourite tool ... which I\nwould hope is not the case :-)\n\nGood luck with this ... you are not alone!\n\nDave Bainbridge\n"},{"id":"144780","messageId":"4C30CB1A.2030407@gnatter.net","threadId":"24133","inReplyTo":"AANLkTimtGoNQe2-nA_Qn_qsZP2Iley9x6TU3Ht28Eg4t@mail.gmail.com","subject":"Re: SVN migration","fromName":"William Hall","fromEmail":"will@gnatter.net","sentAt":"2010-07-04T17:55:38Z","receivedAt":"2010-07-04T17:55:38Z","isPatch":false,"sender":{"key":"will@gnatter.net","avatar":null},"body":"Hi David,\nThanks for your thoughts!\n\nI agree with your points. To an extent, management don't really care how \nwe implement SCM - as long as it's effective and secure they will trust \nthe \"tech-wranglers\" to do the right thing and not impede upon the \ncompany's workflow. Fortunately the industry in which I work is VFX, so \n\"cutting edge\" software is at the core of what we do. I am not imposing \nGit because of my own personal preference, I honestly believe that SVN \nis simply not the right tool for the job - which will increasingly \ninvolve multi-site collaboration that spans departments as well as \ntimezones. The ability for two disparate teams of developers to \ncollaborate effectively without polluting the global codebase is essential.\n\nThe limitations with SVN are becoming more and more apparent - \nespecially now that we have now embarked upon a fairly radical shake-up \nof our existing software stack.\n\nI have explained all this with senior management, some who have heard of \nGit (and its reputation) and they pretty much say \"about time too\".\n\nThe hard part is that we have two tiers of developers - core software \ntechies (C++, python) and scripters (python, MEL - these are the people \nwho make VFX movies, for example, happen). The former will have no \nproblem with Git, the latter probably just don't care - they just want \nto check stuff in and out.)\n\nWhat I need to do is create this hybrid system that enables the \nscripters to pretty much carry on as usual, and to provide the necessary \ntools to do SCM more effectively - ie without the overhead of a brittle \nSVN environment. If all goes well, we'll take the plunge and make the \nswitch permanent.\n\nYes, the technical sell for Git is the easy part, the cultural sell will \nbe harder. It's up to me to make the business case to the bean-counters \nand make the technical transition painless. So far, so good.\n\nI've posted this before, the scripts I am using are available at -\n\nhttp://github.com/innerhippy/svnAndGit\n\nThe more eyes on this the better...\n\nCheers\n\nWill\n\n\n\n\nOn 03/07/10 12:37, David Bainbridge wrote:\n> Hi William,\n>\n> I have been following this thread with interest so I thought that I\n> would just throw in my thoughts!\n>\n> While maintaining synchronization with Git is part of what is needed I\n> suspect that this will not entirely convince the management of your\n> company that Git is the way forward.\n>\n> They probably see Svn as a safe repository ... The company's assets\n> (intellectual property) are on a central server that is backed up, and\n> the contents of that repository can be audited and so on. They may be\n> thinking about things like SOX compliance too.\n>\n> So if you want them to accept Git as a replacement for svn then you\n> need to understand and address these concerns. This means that you\n> will have to have a conversation with them. To a large extent this a\n> people thing ... technical solutions won't necessary convince them.\n> They are running a company based on the knowledge and information they\n> own - and they want to make sure that it doesn't get lost, stolen,\n> corrupted, or whatever. And they are accountable to the shareholders\n> for this.\n>\n> Also, you say that they have been using Svn for donkey's years, so\n> from a corporate perspective it probably does what they want and need.\n> Otherwise THEY would have decided to change it.\n>\n> I am in a similar situation and while developers clearly want to use\n> gIt, the motivation from a corporate perspective is less clear and can\n> be perceived as introducing risk. So we are looking at the wya in\n> which repositories are set up, the topology of git repository\n> networks, use of Gitosis. Gitolite and Gitorious, and so on, to\n> provide some security in the corporate environment.\n>\n> Every company will have a different view of this so there is no\n> 'right' answer. A lot depends on the type of product you produce and\n> how long it will need to be supported. If you have products that need\n> to be supported for 10 years or more then promoting a tool that is 5\n> years old may also raise some eyebrows! You need to have the answers\n> ready :-)\n>\n> Get it right and you will be seen as a hero who understands the\n> business. Get it wrong and you will consigned to the religious nerd\n> category who just wants to promote his favourite tool ... which I\n> would hope is not the case :-)\n>\n> Good luck with this ... you are not alone!\n>\n> Dave Bainbridge\n"},{"id":"144786","messageId":"AANLkTik7yYzUQ7RDaOTYvNIUOxHr6tHfY8cnOoUnVuio@mail.gmail.com","threadId":"24133","inReplyTo":"4C30CB1A.2030407@gnatter.net","subject":"Re: SVN migration","fromName":"David Bainbridge","fromEmail":"david.bainbridge@gmail.com","sentAt":"2010-07-04T22:01:30Z","receivedAt":"2010-07-04T22:01:30Z","isPatch":false,"sender":{"key":"david.bainbridge@gmail.com","avatar":"https://gravatar.com/avatar/1689d4383c7d0d399e2803ddbbecf83b7a4cb9bff89f45917e28b351933ccef1?d=mp&s=160"},"body":"Hi Will,\n\nYou seem to have all the bases covered :-)\n\nIt seems like they have been continuing to use SVN just because it was\nthere, and there was no one willing or able to take them somewhere\nelse, even when the business was changing around them.\n\nThe geographical distribution is an interesting one, because somehow\nsomeone needs to understand what progress is being made with the\nproduct development. With Git it can be easy for people to hide their\n'dirty little secrets' for far too long. This doesn't really matter in\nopen source development, but is an issue for in a commercial\nsituation.\n\nI tend to prefer a central repository and then judge progress by what\nis there. If it isn't there it hasn't been done ...\n\nUnfortunately Git books are not so hot on this aspect of deploying Git :-(\n\nMaybe there are some other ideas out there ...\n\nAll the best,\n\nDavid Bainbridge\nSweden\n\n\n\n\n\n\n\n\n\nOn 4 July 2010 19:55, William Hall <will@gnatter.net> wrote:\n> Hi David,\n> Thanks for your thoughts!\n>\n> I agree with your points. To an extent, management don't really care how we\n> implement SCM - as long as it's effective and secure they will trust the\n> \"tech-wranglers\" to do the right thing and not impede upon the company's\n> workflow. Fortunately the industry in which I work is VFX, so \"cutting edge\"\n> software is at the core of what we do. I am not imposing Git because of my\n> own personal preference, I honestly believe that SVN is simply not the right\n> tool for the job - which will increasingly involve multi-site collaboration\n> that spans departments as well as timezones. The ability for two disparate\n> teams of developers to collaborate effectively without polluting the global\n> codebase is essential.\n>\n> The limitations with SVN are becoming more and more apparent - especially\n> now that we have now embarked upon a fairly radical shake-up of our existing\n> software stack.\n>\n> I have explained all this with senior management, some who have heard of Git\n> (and its reputation) and they pretty much say \"about time too\".\n>\n> The hard part is that we have two tiers of developers - core software\n> techies (C++, python) and scripters (python, MEL - these are the people who\n> make VFX movies, for example, happen). The former will have no problem with\n> Git, the latter probably just don't care - they just want to check stuff in\n> and out.)\n>\n> What I need to do is create this hybrid system that enables the scripters to\n> pretty much carry on as usual, and to provide the necessary tools to do SCM\n> more effectively - ie without the overhead of a brittle SVN environment. If\n> all goes well, we'll take the plunge and make the switch permanent.\n>\n> Yes, the technical sell for Git is the easy part, the cultural sell will be\n> harder. It's up to me to make the business case to the bean-counters and\n> make the technical transition painless. So far, so good.\n>\n> I've posted this before, the scripts I am using are available at -\n>\n> http://github.com/innerhippy/svnAndGit\n>\n> The more eyes on this the better...\n>\n> Cheers\n>\n> Will\n>\n>\n>\n>\n> On 03/07/10 12:37, David Bainbridge wrote:\n>>\n>> Hi William,\n>>\n>> I have been following this thread with interest so I thought that I\n>> would just throw in my thoughts!\n>>\n>> While maintaining synchronization with Git is part of what is needed I\n>> suspect that this will not entirely convince the management of your\n>> company that Git is the way forward.\n>>\n>> They probably see Svn as a safe repository ... The company's assets\n>> (intellectual property) are on a central server that is backed up, and\n>> the contents of that repository can be audited and so on. They may be\n>> thinking about things like SOX compliance too.\n>>\n>> So if you want them to accept Git as a replacement for svn then you\n>> need to understand and address these concerns. This means that you\n>> will have to have a conversation with them. To a large extent this a\n>> people thing ... technical solutions won't necessary convince them.\n>> They are running a company based on the knowledge and information they\n>> own - and they want to make sure that it doesn't get lost, stolen,\n>> corrupted, or whatever. And they are accountable to the shareholders\n>> for this.\n>>\n>> Also, you say that they have been using Svn for donkey's years, so\n>> from a corporate perspective it probably does what they want and need.\n>> Otherwise THEY would have decided to change it.\n>>\n>> I am in a similar situation and while developers clearly want to use\n>> gIt, the motivation from a corporate perspective is less clear and can\n>> be perceived as introducing risk. So we are looking at the wya in\n>> which repositories are set up, the topology of git repository\n>> networks, use of Gitosis. Gitolite and Gitorious, and so on, to\n>> provide some security in the corporate environment.\n>>\n>> Every company will have a different view of this so there is no\n>> 'right' answer. A lot depends on the type of product you produce and\n>> how long it will need to be supported. If you have products that need\n>> to be supported for 10 years or more then promoting a tool that is 5\n>> years old may also raise some eyebrows! You need to have the answers\n>> ready :-)\n>>\n>> Get it right and you will be seen as a hero who understands the\n>> business. Get it wrong and you will consigned to the religious nerd\n>> category who just wants to promote his favourite tool ... which I\n>> would hope is not the case :-)\n>>\n>> Good luck with this ... you are not alone!\n>>\n>> Dave Bainbridge\n>\n"}]}