{"thread":{"id":"13917","subject":"git-svn for vendor branches?","startedAt":"2008-06-12T19:59:04Z","lastAt":"2008-06-12T20:48:49Z","messageCount":2,"participants":["David A. Greene","Avery Pennarun"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"79627","messageId":"200806121459.12570.greened@obbligato.org","threadId":"13917","inReplyTo":null,"subject":"git-svn for vendor branches?","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2008-06-12T19:59:04Z","receivedAt":"2008-06-12T19:59:04Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"I've been reading some things about git-svn and am wondering if it could be\nused to manage vendor branches where both the upstream and local\nrepositories are in svn (don't ask, I didn't set this stuff up).\n\nMy situation looks something like this:\n\nupstream repo (svn)\n  trunk\n  tags\n    release-1.0\n    release-1.1\n    release-1.2\n    ...\n  branches\n    release-1.0\n    release-1.1\n    release-1.2\n    ...\n\nlocal repo (svn, copy of upstream via svn_load_dirs)\n  trunk\n  tags\n  branches\n    release-5.6\n    release-5.7\n    ...\n\nIn the past, we have updated our local trunk from the upstream trunk via \nsvn_load_dirs/svnmerge.  This works ok.  Not good by any means but it's\nat least functional.\n\nThe problem really gets unsolvable with svn when you start looking at \nmerging from upstream *branches.*  In that case, what's in the branch/tag\nis something that appears nowhere on the upstream trunk.  At some point\nit was branched from trunk and stuff was cherry-picked into it from trunk as\nbugs were fixed for release.  So one can't just do an svn_load_dirs from\ntrunk at the point of the branch/tag.  And one can't svn_load_dirs from a\nrelease branch and then svn_load_dirs from trunk later because svn_load_dirs\nby its very nature aggregates lots of individual revisions into one giant one.\nThere's no way to do the merge without a horrible number of conflicts, most\nof which are spurious.\n\nWe really do need to merge from a release branch into our local repository\nand in the future do merges from later release branches or from trunk.\n\nIf everything was in git, this would all be nearly trivial.\n\nBut it's not and I have to deal with it.\n\nNow, there is a git mirror of the upstream repository, presumably kept in\nsync via git-svn.  So my question is, can I somehow do a git-clone of this\nrepository and then use git-svn to \"bounce\" it into our local svn repository\nto do merges?  My reading so far tells me \"no\" but I wanted to check with\nthe gurus.  I believe git-svn only knows about one svn repository and in\nthis case it would be the upstream svn that feeds the public git mirror.\n\nI don't know how people handle this kind of need with svn.\n\nThanks for your help!\n\n                              -Dave\n"},{"id":"79635","messageId":"32541b130806121348u7a52841aicec1e31eaaec8014@mail.gmail.com","threadId":"13917","inReplyTo":"200806121459.12570.greened@obbligato.org","subject":"Re: git-svn for vendor branches?","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-06-12T20:48:49Z","receivedAt":"2008-06-12T20:48:49Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 6/12/08, David A. Greene <greened@obbligato.org> wrote:\n>  The problem really gets unsolvable with svn when you start looking at\n>  merging from upstream *branches.*  In that case, what's in the branch/tag\n>  is something that appears nowhere on the upstream trunk.  At some point\n>  it was branched from trunk and stuff was cherry-picked into it from trunk as\n>  bugs were fixed for release.  So one can't just do an svn_load_dirs from\n>  trunk at the point of the branch/tag.  And one can't svn_load_dirs from a\n>  release branch and then svn_load_dirs from trunk later because svn_load_dirs\n>  by its very nature aggregates lots of individual revisions into one giant one.\n>  There's no way to do the merge without a horrible number of conflicts, most\n>  of which are spurious.\n\nAlthough git-svn does have ways of supporting multiple repositories,\nI'm not really sure git will help much here.  The confusion above\nseems to be that fixes were cherry-picked from trunk into release\nbranches, and now you want to merge release branches together.\nNeither git nor svn tracks cherry picks explicitly, and so they have\nabout the same problems and conflicts when attempting to merge in such\nsituations.\n\nIf I'm wrong about this, I'm sure other people on the list will enlighten me :)\n\n>  We really do need to merge from a release branch into our local repository\n>  and in the future do merges from later release branches or from trunk.\n\nBut the above is a bit easier.  It sounds from the above like most of\nthe cherry-picking difficulties are incurred by the *upstream*\nmaintainers, ie. not you.  Great!  That means someone is already\nresolving those conflicts for you and producing pre-merged releases.\n\nIf I understand correctly, all you really want to do is have your\nlocal repo contain \"some upstream branch that you might want to switch\noccasionally\" + \"my local changes\".  This is quite elegant to do in\ngit with git-rebase (if your local repo switches to git), but it's not\neven so hard to do in svn.\n\nBasically, you just do an svn merge into your local branch of the\ndifferences from (oldbranch@oldrevision) to (newbranch@newrevision).\nIn other words, let's say your current local version is:\n\n    release_1 + local_patches\n\nIf you then apply the changes from release_1 to release_2, you then have:\n\n   release_1 + local_patches + release_1..release_2\n  = release_1 + release_1..release_2 + local_patches\n  = release_2 + local_patches\n\nThis method works for any two svn versions release_1 and release_2.\nYou can bounce back and forth between the trunk and a release branch,\nor downgrade from release_2 to release_1.  The only conflicts you\nshould get are the (unavoidable anyway) conflicts between your local\nchanges and the changes between the two remote branches.\n\nYou can either produce the diff between release_1 and release_2 using\n\"svn diff\" on the remote repo and use plain \"patch\" to apply them to\nthe local copy, or else git_load_dirs the two revisions on your local\ncopy and \"svn merge\" (not \"svnmerge\") between the two.  The latter\nmakes it easier to resolve conflicts.\n\nHave fun,\n\nAvery\n"}]}