{"thread":{"id":"15566","subject":"keep a subversion mirror in sync","startedAt":"2008-09-17T11:58:52Z","lastAt":"2008-09-17T19:04:54Z","messageCount":3,"participants":["Gaspard Bucher","Avery Pennarun"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"90932","messageId":"B529992F-3C09-4708-A3F4-645DB23DF158@teti.ch","threadId":"15566","inReplyTo":null,"subject":"keep a subversion mirror in sync","fromName":"Gaspard Bucher","fromEmail":"gaspard@teti.ch","sentAt":"2008-09-17T11:58:52Z","receivedAt":"2008-09-17T11:58:52Z","isPatch":false,"sender":{"key":"gaspard@teti.ch","avatar":null},"body":"Hi !\n\nI have been trying different strategies to keep subversion repository  \nin sync with a git repository (on github).\n\nSome details with pictures can be found here: http://zenadmin.org/en/documentation/page439.html \n.\n\nI have tried to use a single database to pull/push from github and  \ndcommit to the old subversion repository but I get lots of conflicts  \nand duplicates (see link above).\n\nI have then tried to create a \"pull\" only clone to dcommit, but it  \nlooses the commit messages and replaces then with a merge message. At  \nleast this solution keeps the github repository clean.\n\nWhat is the canonical way to do this ?\n\nMany thanks for your help.\n\nGaspard\n"},{"id":"90962","messageId":"32541b130809171052q4e32e353ld3fdd109d0d34b00@mail.gmail.com","threadId":"15566","inReplyTo":"B529992F-3C09-4708-A3F4-645DB23DF158@teti.ch","subject":"Re: keep a subversion mirror in sync","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-09-17T17:52:28Z","receivedAt":"2008-09-17T17:52:28Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Sep 17, 2008 at 7:58 AM, Gaspard Bucher <gaspard@teti.ch> wrote:\n> I have been trying different strategies to keep subversion repository in\n> sync with a git repository (on github).\n>\n> Some details with pictures can be found here:\n> http://zenadmin.org/en/documentation/page439.html.\n>\n> I have tried to use a single database to pull/push from github and dcommit\n> to the old subversion repository but I get lots of conflicts and duplicates\n> (see link above).\n>\n> I have then tried to create a \"pull\" only clone to dcommit, but it looses\n> the commit messages and replaces then with a merge message. At least this\n> solution keeps the github repository clean.\n>\n> What is the canonical way to do this ?\n\nThe bad news is that a fully automatic two-way sync with svn is pretty\nmuch impossible, AFAIK.  The act of committing to svn adds a\ngit-svn-id line to your commit, so your old commit object needs to be\nthrown away and replaced with a new commit object.  This makes\neverybody else's git commits totally confused.  It's possible that the\nsvn.noMetaData option will avoid this problem, but I've never tried\nit, and it's dangerous: if you lose your svn rev-map database, you\ncan't get it back.\n\nAs for dcommits losing commit messages... yes.  There is no way to\nrepresent the idea of parallel development in svn without creating\nbranches.  For example, if we fetch from svn at point A, and person #1\ncommits to svn based on point A producing point B, and person #2\ncommits to git based on point A producing point C, then in order to\nhave git-svn send point C back into svn, it will have to merge points\nB and C.\n\nGit can do the merge with no problem, but now it has to commit the\nchanges from the merged version into svn.  It doesn't make sense to\ncommit *each* of the commits from A to C, because it would have to do\nit *on top of* B.  The best it can do it commit the entire set of\nchanges as a merge commit.\n\nYou have two options:\n\n1) Manually git-rebase the changes from A..C onto B, then hurry up and\ndcommit them before someone else commits to svn before you (otherwise\nyou'd have to rebase again).  git svn dcommit will then be smart\nenough to commit each one separately.\n\n2) Accept the merge commit.  The good news is that in the git repo,\nhistory will still have all the interesting information; svn's history\nisn't wrong, it's just incomplete.\n\nYou could also try to modify git-svn to implement a third solution:\n\n3) Create a temporary branch in svn by copying commit A.  Commit each\nof the changes from A..C in that branch one by one, then create a\nmerge back on the real branch that merges your temporary branch in,\nusing the commit message and files from your git merge commit.\n\nOption #3 sounds hairy and gross, so it would be a lot of work and\nthere's no guarantee your patch would be accepted.\n\nBasically, svn's limited ability to express history is preventing you\nfrom committing your \"full\" git history back into svn.\n\nAt work, I currently use option #2.  As long as the full history is\navailable *somewhere*, the world is an okay place.\n\nHave fun,\n\nAvery\n"},{"id":"90963","messageId":"5F812637-559B-4454-B624-30CCF5E07351@teti.ch","threadId":"15566","inReplyTo":"32541b130809171052q4e32e353ld3fdd109d0d34b00@mail.gmail.com","subject":"Re: keep a subversion mirror in sync","fromName":"Gaspard Bucher","fromEmail":"gaspard@teti.ch","sentAt":"2008-09-17T19:04:54Z","receivedAt":"2008-09-17T19:04:54Z","isPatch":false,"sender":{"key":"gaspard@teti.ch","avatar":null},"body":"I am the only one writing to the subversion repository. It's just a  \npublic \"read-only\" mirror.\n\nAfter I dcommit, I get a merge commit that's added to the master  \nbranch. The \"origin/master\" does not have this merge commit. When I  \npull from origin/master, I get a conflict\nfor all modified files. Reading the docs, it says \"Running git-merge  \nor git-pull is NOT recommended on a branch you plan to dcommit from\".\n\nI think I will use svk to handle this sync problem.\n\nSETUP:\n1. svk mirror svn://... //mirror/foo\n2. svk sync //mirror/foo\n3. svk co //mirror/foo\n4. cd foo\n5. svk ps svn:ignore \".git\" .\n6. cd ..\n4. rm -rf foo\n5. git clone git@... foo\n6. cd foo\n\nSYNC:\n1. get the last commit message from git and use it to sync back\n\"git log -1 --pretty=short --no-color > /tmp/git_svk_msg && svk ci -- \nimport -F /tmp/git_svk_msg && rm /tmp/git_svk_msg\"\n\nI have tried this setup and it works fine. The fact that svk and git  \ntotally ignore each other is really nice in this situation.\n\nI thought there would be an easier path, but finally the solution here  \nseems good, as long as the \"master\" branch does not contain uncommited  \ncontent.\n\nGaspard\n\n> On Wed, Sep 17, 2008 at 7:58 AM, Gaspard Bucher <gaspard@teti.ch>  \n> wrote:\n>> I have been trying different strategies to keep subversion  \n>> repository in\n>> sync with a git repository (on github).\n>>\n>> Some details with pictures can be found here:\n>> http://zenadmin.org/en/documentation/page439.html.\n>>\n>> I have tried to use a single database to pull/push from github and  \n>> dcommit\n>> to the old subversion repository but I get lots of conflicts and  \n>> duplicates\n>> (see link above).\n>>\n>> I have then tried to create a \"pull\" only clone to dcommit, but it  \n>> looses\n>> the commit messages and replaces then with a merge message. At  \n>> least this\n>> solution keeps the github repository clean.\n>>\n>> What is the canonical way to do this ?\n>\n> The bad news is that a fully automatic two-way sync with svn is pretty\n> much impossible, AFAIK.  The act of committing to svn adds a\n> git-svn-id line to your commit, so your old commit object needs to be\n> thrown away and replaced with a new commit object.  This makes\n> everybody else's git commits totally confused.  It's possible that the\n> svn.noMetaData option will avoid this problem, but I've never tried\n> it, and it's dangerous: if you lose your svn rev-map database, you\n> can't get it back.\n>\n> As for dcommits losing commit messages... yes.  There is no way to\n> represent the idea of parallel development in svn without creating\n> branches.  For example, if we fetch from svn at point A, and person #1\n> commits to svn based on point A producing point B, and person #2\n> commits to git based on point A producing point C, then in order to\n> have git-svn send point C back into svn, it will have to merge points\n> B and C.\n>\n> Git can do the merge with no problem, but now it has to commit the\n> changes from the merged version into svn.  It doesn't make sense to\n> commit *each* of the commits from A to C, because it would have to do\n> it *on top of* B.  The best it can do it commit the entire set of\n> changes as a merge commit.\n>\n> You have two options:\n>\n> 1) Manually git-rebase the changes from A..C onto B, then hurry up and\n> dcommit them before someone else commits to svn before you (otherwise\n> you'd have to rebase again).  git svn dcommit will then be smart\n> enough to commit each one separately.\n>\n> 2) Accept the merge commit.  The good news is that in the git repo,\n> history will still have all the interesting information; svn's history\n> isn't wrong, it's just incomplete.\n>\n> You could also try to modify git-svn to implement a third solution:\n>\n> 3) Create a temporary branch in svn by copying commit A.  Commit each\n> of the changes from A..C in that branch one by one, then create a\n> merge back on the real branch that merges your temporary branch in,\n> using the commit message and files from your git merge commit.\n>\n> Option #3 sounds hairy and gross, so it would be a lot of work and\n> there's no guarantee your patch would be accepted.\n>\n> Basically, svn's limited ability to express history is preventing you\n> from committing your \"full\" git history back into svn.\n>\n> At work, I currently use option #2.  As long as the full history is\n> available *somewhere*, the world is an okay place.\n>\n> Have fun,\n>\n> Avery\n"}]}