{"thread":{"id":"17999","subject":"git-svn and repository hierarchy?","startedAt":"2009-02-24T22:34:12Z","lastAt":"2009-03-08T20:33:40Z","messageCount":24,"participants":["Josef Wolf","Michael J Gruber","Peter Harris","Florian Mickler"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"106119","messageId":"20090224223412.GA4573@raven.wolf.lan","threadId":"17999","inReplyTo":null,"subject":"git-svn and repository hierarchy?","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2009-02-24T22:34:12Z","receivedAt":"2009-02-24T22:34:12Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"Hello,\n\nI have set up a repository hierarchy like this:\n\n\n         subversion-repos\n                |\n           git-svn-repos\n          /     |     \\\n      clone1  clone2  clone3\n\n\nsubversion-repos is an existing repository that can not be converted to\ngit.\n\n\ngit-svn-clone is meant as an intermediate \"synchronization\" repository.\nI never commit directly to this repos.  Its only intention is to\nsynchronize the clones to each other and against subversion-repos.\ngit-svn-clone was created by\n\n     git svn init --stdlayout $svn_url git-svn-repos\n     (cd git-svn-repos && git svn fetch)\n\n\ncloneX are ordinary git clones of git-svn-repos for the day-by-day work.\nThey were created by\n\n     git clone git-svn-repos cloneX\n\n\nI can successfully work on the clones.  To synchronize with git-svn-clone,\nI do\n     git stash\n     git pull\n     git push origin\n     git stash apply\n     git stash clear\nAnd here is my first problem: every time I push to git-svn-repos, its\nworking tree gets out of sync, because pushing don't update the tree.\nSo every time I push, \"git status\" shows me local modifications which\nare actually outdated files.  I thought I could use a bare repository\nto avoid this problem, but git-svn refuses to work on a bare repos.\nSo here's my first question: Any ideas how to get around this?\n\n\nOnce git-svn-repos is cleaned up, I want it to synchronize against\nsubversion-repos.  Thus I do\n\n     git svn rebase\n     git svn dcommit\n\nThis works most of the time.  Sometimes, I get error messages\nlike this from rebase:\n\n  Applying Fix logging of IP-Addresses when reading access list.\n  error: patch failed: upnp/websrv:528\n  error: upnp/websrv: patch does not apply\n  Using index info to reconstruct a base tree...\n  Falling back to patching base and 3-way merge...\n  No changes -- Patch already applied.\n\nI've never seen any damage after this error message, and the last line\nsuggests that this is only some informative warning.\n\n\nBut now here's the real catch:  this time I got following error\nmessage from \"git svn rebase\":\n\n  Auto-merged server/misc.c\n  CONFLICT (content): Merge conflict in server/misc.c\n  Failed to merge in the changes.\n  Patch failed at 0005.\n  \n  When you have resolved this problem run \"git rebase --continue\".\n  If you would prefer to skip this patch, instead run \"git rebase --skip\".\n  To restore the original branch and stop rebasing run \"git rebase --abort\".\n\nUnfortunately, none of the three suggested commands help.\n\nInvestigation reveals that the conflict was caused by two independent\ncommits to one of the clones. That is: both commits were on the same\nclone and no commits were done to the other clones in the mean time.\nThe commits just happen to touch neighboring lines.\n\nThose two commits have managed to go all the way up from cloneA through\ngit-svn-repos to subversion-repos without any problem.  Only on the way\nback from subversion-repos to git-svn-repos, they create the conflict.\n\nAny ideas how to clean up from the situation?  And how to avoid this\nproblem in the future?\n"},{"id":"106183","messageId":"49A50EB2.80300@drmicha.warpmail.net","threadId":"17999","inReplyTo":"20090224223412.GA4573@raven.wolf.lan","subject":"Re: git-svn and repository hierarchy?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-02-25T09:26:10Z","receivedAt":"2009-02-25T09:26:10Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Josef Wolf venit, vidit, dixit 24.02.2009 23:34:\n> Hello,\n> \n> I have set up a repository hierarchy like this:\n> \n> \n>          subversion-repos\n>                 |\n>            git-svn-repos\n>           /     |     \\\n>       clone1  clone2  clone3\n> \n> \n> subversion-repos is an existing repository that can not be converted to\n> git.\n> \n> \n> git-svn-clone is meant as an intermediate \"synchronization\" repository.\n> I never commit directly to this repos.  Its only intention is to\n> synchronize the clones to each other and against subversion-repos.\n> git-svn-clone was created by\n> \n>      git svn init --stdlayout $svn_url git-svn-repos\n>      (cd git-svn-repos && git svn fetch)\n> \n> \n> cloneX are ordinary git clones of git-svn-repos for the day-by-day work.\n> They were created by\n> \n>      git clone git-svn-repos cloneX\n> \n> \n> I can successfully work on the clones.  To synchronize with git-svn-clone,\n> I do\n>      git stash\n>      git pull\n>      git push origin\n>      git stash apply\n>      git stash clear\n> And here is my first problem: every time I push to git-svn-repos, its\n> working tree gets out of sync, because pushing don't update the tree.\n> So every time I push, \"git status\" shows me local modifications which\n> are actually outdated files.  I thought I could use a bare repository\n> to avoid this problem, but git-svn refuses to work on a bare repos.\n> So here's my first question: Any ideas how to get around this?\n\nRecent enough git should even warn you against doing that, \"that\" being\npushing into checked out branches.\n\nYour diagram above is missing important info, namely which branches you\nare pushing into. But the problem indicates that you are pushing into a\nchecked out branch.\n\ngit-svn can't operate on bare repos beacuse rebasing needs a worktree.\n\n> Once git-svn-repos is cleaned up, I want it to synchronize against\n> subversion-repos.  Thus I do\n> \n>      git svn rebase\n>      git svn dcommit\n> \n> This works most of the time.  Sometimes, I get error messages\n> like this from rebase:\n> \n>   Applying Fix logging of IP-Addresses when reading access list.\n>   error: patch failed: upnp/websrv:528\n>   error: upnp/websrv: patch does not apply\n>   Using index info to reconstruct a base tree...\n>   Falling back to patching base and 3-way merge...\n>   No changes -- Patch already applied.\n> \n> I've never seen any damage after this error message, and the last line\n> suggests that this is only some informative warning.\n> \n> \n> But now here's the real catch:  this time I got following error\n> message from \"git svn rebase\":\n> \n>   Auto-merged server/misc.c\n>   CONFLICT (content): Merge conflict in server/misc.c\n>   Failed to merge in the changes.\n>   Patch failed at 0005.\n>   \n>   When you have resolved this problem run \"git rebase --continue\".\n>   If you would prefer to skip this patch, instead run \"git rebase --skip\".\n>   To restore the original branch and stop rebasing run \"git rebase --abort\".\n> \n> Unfortunately, none of the three suggested commands help.\n> \n> Investigation reveals that the conflict was caused by two independent\n> commits to one of the clones. That is: both commits were on the same\n> clone and no commits were done to the other clones in the mean time.\n> The commits just happen to touch neighboring lines.\n> \n> Those two commits have managed to go all the way up from cloneA through\n> git-svn-repos to subversion-repos without any problem.  Only on the way\n> back from subversion-repos to git-svn-repos, they create the conflict.\n> \n> Any ideas how to clean up from the situation?  And how to avoid this\n> problem in the future?\n\nIn your git-svn-repo you need more branches in order to do the\nintegration work:\n\n>From your clones, push into branches like remotes/incoming/clone1 or\nremotes/clone1/master etc. on your git-svn-repo. Using remote branches\nthere makes sure they will never be checked out.\n\nThen, on git-svn-repo, you need to integrate the incoming clone branches\nwith the svn branches:\n\n- rebase master first using git svn rebase\n- If this fetches new revisions from svn it means that your clones were\nnot up to date. Decide now whether you want to rebase your clones first\nand resolve any possible conflicts there (i.e.: git fetch on the clones,\nrebase your changes on top, git push to incoming) or want to continue here.\n- Integrate the incoming clone branches on top of master. If git svn\nfetched new revisions in the previous step then master can't be fast\nforwarded to the incoming clone branch tip. You'll have to cherry-pick\nor use format-patch|am.\n- Now dcommit.\n\nAFAICS, the problem in a git-svn workflow is always svn's missing merge\ncapabilities whenever svn and git development diverge, such as when your\nclones develop on top of a svn revision which is not current any more.\nSomewhere the integration work has to done, and it will involve a\nrebase. I think it's easier to do the rebase on the clone because it's\n\"pure git\" there, i.e.: If git-svn fetches new stuff go back and do the\nwork on the clone. The only problem is if this is a quickly moving target.\n\nMichael\n\nP.S.: Uh, did somebody say cleanup? Who made the mess? ;)\n"},{"id":"106275","messageId":"20090225232442.GC4573@raven.wolf.lan","threadId":"17999","inReplyTo":"49A50EB2.80300@drmicha.warpmail.net","subject":"Re: git-svn and repository hierarchy?","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2009-02-25T23:24:42Z","receivedAt":"2009-02-25T23:24:42Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"Thanks for your fast response, Michael!\n\nOn Wed, Feb 25, 2009 at 10:26:10AM +0100, Michael J Gruber wrote:\n> Josef Wolf venit, vidit, dixit 24.02.2009 23:34:\n> > I have set up a repository hierarchy like this:\n> > \n> > \n> >          subversion-repos\n> >                 |\n> >            git-svn-repos\n> >           /     |     \\\n> >       clone1  clone2  clone3\n[ ... ]\n> > And here is my first problem: every time I push to git-svn-repos, its\n> > working tree gets out of sync, because pushing don't update the tree.\n> > So every time I push, \"git status\" shows me local modifications which\n> > are actually outdated files.  I thought I could use a bare repository\n> > to avoid this problem, but git-svn refuses to work on a bare repos.\n> > So here's my first question: Any ideas how to get around this?\n> \n> Recent enough git should even warn you against doing that, \"that\" being\n> pushing into checked out branches.\n> \n> Your diagram above is missing important info, namely which branches you\n> are pushing into. But the problem indicates that you are pushing into a\n> checked out branch.\n\nYeah, although I have read countless tutorials/howtos/blogs, I have still\nnot managed to setup my mental mode in a way compatible with git.  Guess\nsubversion has carved my brains for too long a time ;-)\n\n> git-svn can't operate on bare repos beacuse rebasing needs a worktree.\n\nHmm, is this required by the design or is that just an implementation\ndetail (which, at least in theory, could be re-factored away)?\n\n> > Any ideas how to clean up from the situation?  And how to avoid this\n> > problem in the future?\n> \n> In your git-svn-repo you need more branches in order to do the\n> integration work:\n> \n> From your clones, push into branches like remotes/incoming/clone1 or\n> remotes/clone1/master etc. on your git-svn-repo. Using remote branches\n> there makes sure they will never be checked out.\n\nOK, makes sense.  But there's a drawback: this way I need to keep track\nwithin git-svn-repos which clones exist.  The intent of git-svn-repos\nwas to provide a central git interface to the subversion-repos for\nother developers.  And I'd rather not want to track manually all the\nclones/branches they create.\n\n> Then, on git-svn-repo, you need to integrate the incoming clone branches\n> with the svn branches:\n> \n> - rebase master first using git svn rebase\n> - If this fetches new revisions from svn it means that your clones were\n> not up to date. Decide now whether you want to rebase your clones first\n> and resolve any possible conflicts there (i.e.: git fetch on the clones,\n> rebase your changes on top, git push to incoming) or want to continue here.\n> - Integrate the incoming clone branches on top of master. If git svn\n> fetched new revisions in the previous step then master can't be fast\n> forwarded to the incoming clone branch tip. You'll have to cherry-pick\n> or use format-patch|am.\n> - Now dcommit.\n\nI am not sure I completely understand the details how to setup the\nrepositories.  Can you please provide an example?\n\nHowever, I think I got some understanding of the basic workflow.\nAnd IMHO, there's one catch: to synchronize, I need to tightly\ncoordinate the work on git-svn-repos with the work on its clones.  The\nclones are not reachable most of the time, so tightly coordinating\nwould slow down the flow of changesets extremely.\n\nMaybe things can be improved by introducing one more hierarchy:\n \n          subversion-repos\n                 |\n            git-svn-repos\n                 |\n           bare-git-repos\n           /     |     \\\n       clone1  clone2  clone3\n\nor something?  bare-git-repos would make it possible for the clones\nto push their work, and I have no longer to keep track of all the\nclones, right?  For the merge work within git-svn-repos, only\nbare-git-repos need to be available, so missing clones would not slow\ndown the flow of changesets.\n\n> AFAICS, the problem in a git-svn workflow is always svn's missing merge\n> capabilities whenever svn and git development diverge, such as when your\n> clones develop on top of a svn revision which is not current any more.\n\nI don't see why svn's merge capabilities affect merges done within\ngit-svn-repos (or even within its clones).  And in fact, in the example\nI described, the merge _was_ actually done within one of the clones.\nAnd the merged data arrived in the svn repos correctly.  The conflict\nhappens at the time the changesets go the way back with \"git svn rebase\"\nAt that time, git-svn tries to apply the changesets within its .dotest\ndirectory.  Because they already were applied when they came from the\nclone, we got a collision.\n\nI am pretty sure I am missing something important.  But AFAICS, git-svn\nshould not try to apply the changesets it has sent itself to svn,\nbecause those changesets are already applied.  Normally, you would get\nonly some \"already applied\" warning.  But in the case when hunks are\noverlapping, this leads to a conflict.\n\n> Somewhere the integration work has to done, and it will involve a\n> rebase. I think it's easier to do the rebase on the clone because it's\n> \"pure git\" there, i.e.: If git-svn fetches new stuff go back and do the\n> work on the clone. The only problem is if this is a quickly moving target.\n\nWell, and the second problem is that most of the clones are not (and\nshould not) be under my control.  So I can not simply go to the clone to\ndo the integration work there.\n\n> P.S.: Uh, did somebody say cleanup? Who made the mess? ;)\n\nGuess, that's me.  That's why I asked _how_ to cleanup ;-)\n"},{"id":"106279","messageId":"eaa105840902251702l68bc35f3ia15b1c804a6825f3@mail.gmail.com","threadId":"17999","inReplyTo":"20090225232442.GC4573@raven.wolf.lan","subject":"Re: git-svn and repository hierarchy?","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2009-02-26T01:02:45Z","receivedAt":"2009-02-26T01:02:45Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Wed, Feb 25, 2009 at 6:24 PM, Josef Wolf wrote:\n> And IMHO, there's one catch: to synchronize, I need to tightly\n> coordinate the work on git-svn-repos with the work on its clones.  The\n> clones are not reachable most of the time, so tightly coordinating\n> would slow down the flow of changesets extremely.\n\nNot sure if it helps, but for what it's worth, I use a circular setup:\ngit-svn-repos is updated from subversion-repos (by cron), but is\notherwise read-only. cloneN can pull from git-svn-repos (since\ngit-pull is a whole lot faster than git svn fetch, especially for the\ninitial clone), but has to \"git svn dcommit\" to push changes back\nupstream.\n\nThis configuration puts any potential rebase conflicts back into the\nhands of cloneN. No need to coordinate clones, aside from each clone\nneeding to know how to work in a \"commits will be rebased by upstream\"\ntype of environment (which isn't unique to git-svn). Oh, and make sure\nyou're using a recent git; older git-svn didn't have the incremental\nindex rebuild.\n\nPeter Harris\n"},{"id":"106446","messageId":"20090227165812.GA14187@raven.wolf.lan","threadId":"17999","inReplyTo":"eaa105840902251702l68bc35f3ia15b1c804a6825f3@mail.gmail.com","subject":"Re: git-svn and repository hierarchy?","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2009-02-27T16:58:12Z","receivedAt":"2009-02-27T16:58:12Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"On Wed, Feb 25, 2009 at 08:02:45PM -0500, Peter Harris wrote:\n> On Wed, Feb 25, 2009 at 6:24 PM, Josef Wolf wrote:\n> > And IMHO, there's one catch: to synchronize, I need to tightly\n> > coordinate the work on git-svn-repos with the work on its clones.  The\n> > clones are not reachable most of the time, so tightly coordinating\n> > would slow down the flow of changesets extremely.\n> \n> Not sure if it helps, but for what it's worth, I use a circular setup:\n> git-svn-repos is updated from subversion-repos (by cron), but is\n> otherwise read-only. cloneN can pull from git-svn-repos (since\n> git-pull is a whole lot faster than git svn fetch, especially for the\n> initial clone), but has to \"git svn dcommit\" to push changes back\n> upstream.\n> \n> This configuration puts any potential rebase conflicts back into the\n> hands of cloneN.\n\nThanks for the suggestion, Peter!  I guess this would really solve\nthe problem.\n\n> No need to coordinate clones, aside from each clone\n> needing to know how to work in a \"commits will be rebased by upstream\"\n> type of environment (which isn't unique to git-svn).\n\nHmm, what does that exactly mean?  Chances are that the reason for my\nproblem is that _I_ am the one who don't know that...\n\n> Oh, and make sure\n> you're using a recent git; older git-svn didn't have the incremental\n> index rebuild.\n\njw@raven:/home/jw> git --version\ngit version 1.6.0.2\njw@raven:/home/jw>\n\nIs that OK?\n"},{"id":"106447","messageId":"20090227171248.GB14187@raven.wolf.lan","threadId":"17999","inReplyTo":"49A50EB2.80300@drmicha.warpmail.net","subject":"Re: git-svn and repository hierarchy?","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2009-02-27T17:12:48Z","receivedAt":"2009-02-27T17:12:48Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"On Wed, Feb 25, 2009 at 10:26:10AM +0100, Michael J Gruber wrote:\n> Josef Wolf venit, vidit, dixit 24.02.2009 23:34:\n\n> > I have set up a repository hierarchy like this:\n> > \n> > \n> >          subversion-repos\n> >                 |\n> >            git-svn-repos\n> >           /     |     \\\n> >       clone1  clone2  clone3\n>\n> Recent enough git should even warn you against doing that, \"that\" being\n> pushing into checked out branches.\n\nI've now tried to synchronize via pull instead of push, but I still\nget conflicts.\n\n> Your diagram above is missing important info, namely which branches you\n> are pushing into. But the problem indicates that you are pushing into a\n> checked out branch.\n\nIn order to get a better understanding what's going on, I've written a\nsmall script which can be copy-pasted into some terminal window:\n\n(\n  set -ex\n\n  # create test directory\n  #\n  TESTDIR=`mktemp --tmpdir=. git-svn-hierarchy-test-XXXXXXXX`\n  rm -rf $TESTDIR\n  mkdir -p $TESTDIR\n  cd $TESTDIR\n\n  SUBVERSION_REPOS=file://`pwd`/subversion-repos\n\n  # create subversion repos with some history\n  #\n  svnadmin create subversion-repos\n  svn -m \"create standard layout\" mkdir \\\n      $SUBVERSION_REPOS/trunk \\\n      $SUBVERSION_REPOS/branches \\\n      $SUBVERSION_REPOS/tags\n  svn co $SUBVERSION_REPOS/trunk subversion-wc\n  echo change1 >>subversion-wc/test\n  svn add subversion-wc/test\n  svn ci -m \"commit 1\" subversion-wc\n\n  # create git-svn-repos\n  #\n  git svn init --stdlayout $SUBVERSION_REPOS git-svn-repos\n  (cd git-svn-repos; git svn fetch)\n\n  # create a clone and do some work on it\n  #\n  git clone git-svn-repos clone1\n  for i in 2 3 4; do\n    ( cd clone1; echo change$i >>test ; git commit -a -m \"commit $i\")\n  done\n\n  (cd git-svn-repos; git pull ../clone1)\n  (cd git-svn-repos; git svn rebase)\n  (cd git-svn-repos; git svn dcommit)\n  (cd git-svn-repos; git pull ../clone1)  # if this line is executed,\n  (cd git-svn-repos; git svn rebase)      # this command gives the conflict\n)\n\nWhen I comment out the second \"git pull ../clone1\", the conflict does\nnot happen on the last \"git svn rebase\", but on some later pull, rebase\nor dcommit command.\n\nObviously, I'm doing something wrong.  But I can't figure what.  Any hints?\n"},{"id":"106451","messageId":"49A826C8.1060300@drmicha.warpmail.net","threadId":"17999","inReplyTo":"20090227171248.GB14187@raven.wolf.lan","subject":"Re: git-svn and repository hierarchy?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-02-27T17:45:44Z","receivedAt":"2009-02-27T17:45:44Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Josef Wolf venit, vidit, dixit 27.02.2009 18:12:\n> On Wed, Feb 25, 2009 at 10:26:10AM +0100, Michael J Gruber wrote:\n>> Josef Wolf venit, vidit, dixit 24.02.2009 23:34:\n> \n>>> I have set up a repository hierarchy like this:\n>>>\n>>>\n>>>          subversion-repos\n>>>                 |\n>>>            git-svn-repos\n>>>           /     |     \\\n>>>       clone1  clone2  clone3\n>> Recent enough git should even warn you against doing that, \"that\" being\n>> pushing into checked out branches.\n> \n> I've now tried to synchronize via pull instead of push, but I still\n> get conflicts.\n> \n>> Your diagram above is missing important info, namely which branches you\n>> are pushing into. But the problem indicates that you are pushing into a\n>> checked out branch.\n> \n> In order to get a better understanding what's going on, I've written a\n> small script which can be copy-pasted into some terminal window:\n> \n> (\n>   set -ex\n> \n>   # create test directory\n>   #\n>   TESTDIR=`mktemp --tmpdir=. git-svn-hierarchy-test-XXXXXXXX`\n>   rm -rf $TESTDIR\n>   mkdir -p $TESTDIR\n>   cd $TESTDIR\n> \n>   SUBVERSION_REPOS=file://`pwd`/subversion-repos\n> \n>   # create subversion repos with some history\n>   #\n>   svnadmin create subversion-repos\n>   svn -m \"create standard layout\" mkdir \\\n>       $SUBVERSION_REPOS/trunk \\\n>       $SUBVERSION_REPOS/branches \\\n>       $SUBVERSION_REPOS/tags\n>   svn co $SUBVERSION_REPOS/trunk subversion-wc\n>   echo change1 >>subversion-wc/test\n>   svn add subversion-wc/test\n>   svn ci -m \"commit 1\" subversion-wc\n> \n>   # create git-svn-repos\n>   #\n>   git svn init --stdlayout $SUBVERSION_REPOS git-svn-repos\n>   (cd git-svn-repos; git svn fetch)\n> \n>   # create a clone and do some work on it\n>   #\n>   git clone git-svn-repos clone1\n>   for i in 2 3 4; do\n>     ( cd clone1; echo change$i >>test ; git commit -a -m \"commit $i\")\n>   done\n> \n>   (cd git-svn-repos; git pull ../clone1)\n\nGives you 1-2-3-4\n\n>   (cd git-svn-repos; git svn rebase)\n\nDoes nothing here (but is good practice)\n\n>   (cd git-svn-repos; git svn dcommit)\n\nCreates 2-3-4 on the svn side. *Then rebases* your master, which creates\n1-2'-3'-4' on master. Note that 2 is different from 2' (git-svn id).\n\n>   (cd git-svn-repos; git pull ../clone1)  # if this line is executed,\n\nThat's the problem. This creates a merge after which you 1-2-3-4 and\n1-2'-3'-4' plus the merge of 4 and 4'.\n\nInstead, use git pull --rebase here. You don't want merges in the branch\nfrom which you dcommit.\n\nBorrowing from some other vcs:\n\nRepeat the soothing mantra: a merge is no merge is no merge - it it's in\nsvn ;)\n\n>   (cd git-svn-repos; git svn rebase)      # this command gives the conflict\n> )\n> \n> When I comment out the second \"git pull ../clone1\", the conflict does\n> not happen on the last \"git svn rebase\", but on some later pull, rebase\n> or dcommit command.\n> \n> Obviously, I'm doing something wrong.  But I can't figure what.  Any hints?\n\nI guess when we said integrated we should have said rebase. Haven't we?\n\nCheers,\nMichael\n"},{"id":"106454","messageId":"eaa105840902271011u19375ba4j4a765ed2707ebb3b@mail.gmail.com","threadId":"17999","inReplyTo":"20090227165812.GA14187@raven.wolf.lan","subject":"Re: git-svn and repository hierarchy?","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2009-02-27T18:11:36Z","receivedAt":"2009-02-27T18:11:36Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Fri, Feb 27, 2009 at 11:58 AM, Josef Wolf wrote:\n> On Wed, Feb 25, 2009 at 08:02:45PM -0500, Peter Harris wrote:\n>\n>> No need to coordinate clones, aside from each clone\n>> needing to know how to work in a \"commits will be rebased by upstream\"\n>> type of environment (which isn't unique to git-svn).\n>\n> Hmm, what does that exactly mean?  Chances are that the reason for my\n> problem is that _I_ am the one who don't know that...\n\nSee, for example,\nhttp://kerneltrap.org/mailarchive/git/2008/8/23/3056824 and\nsurrounding thread.\n\nThe consensus is \"Pester upstream until they stop rebasing\".\nUnfortunately, Subversion is an application, not a human, so your\npleas will go unheard. :-) The rest of that thread contains hints for\nworking with a rebasing upstream.\n\ngit-svn will actually never rebase anything once it is in Subversion.\nSo, for example, when they say 'linux-next' in that thread, you could\nread \"any branch that isn't in Subversion yet\", since you know that\nbranch will be rebased at least once.\n\n>> Oh, and make sure\n>> you're using a recent git; older git-svn didn't have the incremental\n>> index rebuild.\n>\n> jw@raven:/home/jw> git --version\n> git version 1.6.0.2\n> jw@raven:/home/jw>\n>\n> Is that OK?\n\n2beec8973 is the commit in question. Unless I'm mistaken, it first\nappeared in 1.6.1.0, so you may want to upgrade each cloneN to at\nleast 1.6.1.\n\nPeter Harris\n"},{"id":"106484","messageId":"20090227220512.GC14187@raven.wolf.lan","threadId":"17999","inReplyTo":"49A826C8.1060300@drmicha.warpmail.net","subject":"Re: git-svn and repository hierarchy?","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2009-02-27T22:05:12Z","receivedAt":"2009-02-27T22:05:12Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"Thanks for your patience, Michael!\n\nOn Fri, Feb 27, 2009 at 06:45:44PM +0100, Michael J Gruber wrote:\n> Josef Wolf venit, vidit, dixit 27.02.2009 18:12:\n> > On Wed, Feb 25, 2009 at 10:26:10AM +0100, Michael J Gruber wrote:\n> >> Josef Wolf venit, vidit, dixit 24.02.2009 23:34:\n\n[ ... ]\n> >   (cd git-svn-repos; git pull ../clone1)\n> \n> Gives you 1-2-3-4\n> \n> >   (cd git-svn-repos; git svn rebase)\n> \n> Does nothing here (but is good practice)\n> \n> >   (cd git-svn-repos; git svn dcommit)\n> \n> Creates 2-3-4 on the svn side. *Then rebases* your master, which creates\n> 1-2'-3'-4' on master. Note that 2 is different from 2' (git-svn id).\n\nSo the sha1 is not preserved when it goes through svn?\n\n> >   (cd git-svn-repos; git pull ../clone1)  # if this line is executed,\n> \n> That's the problem. This creates a merge after which you 1-2-3-4 and\n> 1-2'-3'-4' plus the merge of 4 and 4'.\n\n--verbosity=on please ;-)\n\n> Instead, use git pull --rebase here. You don't want merges in the branch\n> from which you dcommit.\n\nYeah, \"pull --rebase\" seems to help a lot.  So I've come up with the next\nversion of my workflow-test-script:\n\n(\n  set -ex\n\n  # create test directory\n  #\n  TESTDIR=`mktemp --tmpdir=. git-svn-hierarchy-test-XXXXXXXX`\n  rm -rf $TESTDIR\n  mkdir -p $TESTDIR\n  cd $TESTDIR\n\n  SUBVERSION_REPOS=file://`pwd`/subversion-repos\n\n  # create subversion repos with some history\n  #\n  svnadmin create subversion-repos\n  svn -m \"create standard layout\" mkdir \\\n      $SUBVERSION_REPOS/trunk \\\n      $SUBVERSION_REPOS/branches \\\n      $SUBVERSION_REPOS/tags\n  svn co $SUBVERSION_REPOS/trunk subversion-wc\n  echo change1 >>subversion-wc/test\n  svn add subversion-wc/test\n  svn ci -m \"commit 0\" subversion-wc\n\n  # create git-svn-repos\n  #\n  git svn init --stdlayout $SUBVERSION_REPOS git-svn-repos\n  (cd git-svn-repos; git svn fetch)\n\n  # create clones\n  #\n  git clone git-svn-repos clone1\n  git clone git-svn-repos clone2\n  git clone git-svn-repos clone3\n\n  # now go several times to every clone, do some work on it, and sync\n  # the results\n  #\n  for cycle in 1 2 3; do\n    for clone in 1 2 3; do\n      for commit in 1 2 3; do\n        (\n          cd clone$clone\n          git pull --rebase\n          echo change $clone $commit >>test\n          git commit -a -m \"commit $clone $commit\"\n        )\n      done\n      (cd git-svn-repos; git pull --rebase ../clone$clone)\n      (cd git-svn-repos; git svn rebase)\n      (cd git-svn-repos; git svn dcommit)\n    done\n  done\n)\n\nAt least, this seems to not creating collisions any more.  But I'm still\nnot sure I fully understand what's going on here.  Guess, I'll have to\nget into the learning-by-doing mode :)\n\n> Borrowing from some other vcs:\n> \n> Repeat the soothing mantra: a merge is no merge is no merge - it it's in\n> svn ;)\n\nHuh?\n\n> > Obviously, I'm doing something wrong.  But I can't figure what.  Any hints?\n> \n> I guess when we said integrated we should have said rebase. Haven't we?\n\nYou like to talk in riddles? Aren't you?\n\nThanks a lot.\n"},{"id":"106489","messageId":"20090227235824.GD14187@raven.wolf.lan","threadId":"17999","inReplyTo":"eaa105840902271011u19375ba4j4a765ed2707ebb3b@mail.gmail.com","subject":"Re: git-svn and repository hierarchy?","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2009-02-27T23:58:25Z","receivedAt":"2009-02-27T23:58:25Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"On Fri, Feb 27, 2009 at 01:11:36PM -0500, Peter Harris wrote:\n> On Fri, Feb 27, 2009 at 11:58 AM, Josef Wolf wrote:\n> > On Wed, Feb 25, 2009 at 08:02:45PM -0500, Peter Harris wrote:\n> >\n> >> No need to coordinate clones, aside from each clone\n> >> needing to know how to work in a \"commits will be rebased by upstream\"\n> >> type of environment (which isn't unique to git-svn).\n> >\n> > Hmm, what does that exactly mean?  Chances are that the reason for my\n> > problem is that _I_ am the one who don't know that...\n> \n> See, for example,\n> http://kerneltrap.org/mailarchive/git/2008/8/23/3056824 and\n> surrounding thread.\n> \n> The consensus is \"Pester upstream until they stop rebasing\".\n> Unfortunately, Subversion is an application, not a human, so your\n> pleas will go unheard. :-) The rest of that thread contains hints for\n> working with a rebasing upstream.\n\nThanks for the pointer, Peter!  That's a long thread with a lot of\ndense information.  I'm going to read (and try to understand :),\nbut I guess it will take a couple of days...\n\n> git-svn will actually never rebase anything once it is in Subversion.\n> So, for example, when they say 'linux-next' in that thread, you could\n> read \"any branch that isn't in Subversion yet\", since you know that\n> branch will be rebased at least once.\n\nAt the time I read the tutorials/howtos/whatever, I thought I understand\nwhat \"rebase\" actually means.  But now I get pretty much confused, since\nthere are \"git rebase\", \"git pull --rebase\" and \"git svn rebase\" involved,\nand they all seem to do very different things.\n\n> > jw@raven:/home/jw> git --version\n> > git version 1.6.0.2\n> > jw@raven:/home/jw>\n> \n> 2beec8973 is the commit in question. Unless I'm mistaken, it first\n> appeared in 1.6.1.0, so you may want to upgrade each cloneN to at\n> least 1.6.1.\n\nOK.\n"},{"id":"106503","messageId":"eaa105840902271841p2cb45eb1ye0bafb136c0cceaf@mail.gmail.com","threadId":"17999","inReplyTo":"20090227235824.GD14187@raven.wolf.lan","subject":"Re: git-svn and repository hierarchy?","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2009-02-28T02:41:02Z","receivedAt":"2009-02-28T02:41:02Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Fri, Feb 27, 2009 at 6:58 PM, Josef Wolf wrote:\n>\n> At the time I read the tutorials/howtos/whatever, I thought I understand\n> what \"rebase\" actually means.  But now I get pretty much confused, since\n> there are \"git rebase\", \"git pull --rebase\" and \"git svn rebase\" involved,\n> and they all seem to do very different things.\n\n(simplified, take with grain of salt:)\n\"git pull\" is short for \"git fetch && git merge <tracking branch>\"\n\"git pull --rebase\" is short for \"git fetch && git rebase <tracking branch>\"\n\"git svn rebase\" is short for \"git svn fetch && git rebase <svn\ntracking branch>\"\n\"git svn dcommit\" is short for \"while (changes) { svn ci && git svn rebase }\"\n\nIt's all just shortcuts for the same operations underneath. Does that help?\n\nPeter Harris\n"},{"id":"106545","messageId":"49A97B7A.8010005@drmicha.warpmail.net","threadId":"17999","inReplyTo":"20090227220512.GC14187@raven.wolf.lan","subject":"Re: git-svn and repository hierarchy?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-02-28T17:59:22Z","receivedAt":"2009-02-28T17:59:22Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Josef Wolf venit, vidit, dixit 27.02.2009 23:05:\n> Thanks for your patience, Michael!\n> \n> On Fri, Feb 27, 2009 at 06:45:44PM +0100, Michael J Gruber wrote:\n>> Josef Wolf venit, vidit, dixit 27.02.2009 18:12:\n>>> On Wed, Feb 25, 2009 at 10:26:10AM +0100, Michael J Gruber wrote:\n>>>> Josef Wolf venit, vidit, dixit 24.02.2009 23:34:\n> \n> [ ... ]\n>>>   (cd git-svn-repos; git pull ../clone1)\n>> Gives you 1-2-3-4\n>>\n>>>   (cd git-svn-repos; git svn rebase)\n>> Does nothing here (but is good practice)\n>>\n>>>   (cd git-svn-repos; git svn dcommit)\n>> Creates 2-3-4 on the svn side. *Then rebases* your master, which creates\n>> 1-2'-3'-4' on master. Note that 2 is different from 2' (git-svn id).\n> \n> So the sha1 is not preserved when it goes through svn?\n\nNo. Once your commits come back from svn through git-svn they have an\nadditional line in the commit. Also, the commit time time will be\ndifferent, and the author name might be depending on your name remapping.\n\nThe patch-id (which only looks at the actual diff being introduced)\nshould be the same.\n\n>>>   (cd git-svn-repos; git pull ../clone1)  # if this line is executed,\n>> That's the problem. This creates a merge after which you 1-2-3-4 and\n>> 1-2'-3'-4' plus the merge of 4 and 4'.\n> \n> --verbosity=on please ;-)\n\nNo such option \"--verbosity\". ;)\n\nUhm, I'm just not good at diagramms in ascii. You had 1-2-3-4 in\ngit-svn-repo. 2, 3 and 4 were dcommit to svn and came back as 2', 3',\n4', such that git-svn rebased your master branch in git-svn-repo and\nmaster looked like 1-2'-3'-4'. The primed version are the one with an\nadditional git-svn-id line in the commit: different sha1 from the\nunprimed version, same patch-id.\n\nNow, if you say pull ../clone1, you fetch from there and merges\nFETCH_HEAD, i.e. the tip of ../clone1, which is 4. So you get\n\n1-2'-3'-4'-o\n \\        /\n  2 -3 -4\n\nwith o being the tip (HEAD) of master. And that is the problem, because\nno history is not linear in master, and the next git-svn dcommit won't\nknow what to do.\n\n>> Instead, use git pull --rebase here. You don't want merges in the branch\n>> from which you dcommit.\n> \n> Yeah, \"pull --rebase\" seems to help a lot.  So I've come up with the next\n> version of my workflow-test-script:\n> \n> (\n>   set -ex\n> \n>   # create test directory\n>   #\n>   TESTDIR=`mktemp --tmpdir=. git-svn-hierarchy-test-XXXXXXXX`\n>   rm -rf $TESTDIR\n>   mkdir -p $TESTDIR\n>   cd $TESTDIR\n> \n>   SUBVERSION_REPOS=file://`pwd`/subversion-repos\n> \n>   # create subversion repos with some history\n>   #\n>   svnadmin create subversion-repos\n>   svn -m \"create standard layout\" mkdir \\\n>       $SUBVERSION_REPOS/trunk \\\n>       $SUBVERSION_REPOS/branches \\\n>       $SUBVERSION_REPOS/tags\n>   svn co $SUBVERSION_REPOS/trunk subversion-wc\n>   echo change1 >>subversion-wc/test\n>   svn add subversion-wc/test\n>   svn ci -m \"commit 0\" subversion-wc\n> \n>   # create git-svn-repos\n>   #\n>   git svn init --stdlayout $SUBVERSION_REPOS git-svn-repos\n>   (cd git-svn-repos; git svn fetch)\n> \n>   # create clones\n>   #\n>   git clone git-svn-repos clone1\n>   git clone git-svn-repos clone2\n>   git clone git-svn-repos clone3\n> \n>   # now go several times to every clone, do some work on it, and sync\n>   # the results\n>   #\n>   for cycle in 1 2 3; do\n>     for clone in 1 2 3; do\n>       for commit in 1 2 3; do\n>         (\n>           cd clone$clone\n>           git pull --rebase\n>           echo change $clone $commit >>test\n>           git commit -a -m \"commit $clone $commit\"\n>         )\n>       done\n>       (cd git-svn-repos; git pull --rebase ../clone$clone)\n>       (cd git-svn-repos; git svn rebase)\n>       (cd git-svn-repos; git svn dcommit)\n>     done\n>   done\n> )\n> \n> At least, this seems to not creating collisions any more.  But I'm still\n> not sure I fully understand what's going on here.  Guess, I'll have to\n> get into the learning-by-doing mode :)\n\nYes, be sure to check the DAG (the graph of commits which you produced)\nusing something like gitk or git log --graph with the \"--all\" argument\nso that you see all branches!\n\n>> Borrowing from some other vcs:\n>>\n>> Repeat the soothing mantra: a merge is no merge is no merge - it it's in\n>> svn ;)\n> \n> Huh?\n\nI meant \"if it's\", sorry for the typo.\nIf you don't get the plug don't worry (or look up hg) ;)\n\n>>> Obviously, I'm doing something wrong.  But I can't figure what.  Any hints?\n>> I guess when we said integrated we should have said rebase. Haven't we?\n> \n> You like to talk in riddles? Aren't you?\n\nNo, I'm not ;)\n\nMichael\n"},{"id":"106912","messageId":"20090303185108.GA11278@raven.wolf.lan","threadId":"17999","inReplyTo":"49A97B7A.8010005@drmicha.warpmail.net","subject":"Re: git-svn and repository hierarchy?","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2009-03-03T18:51:08Z","receivedAt":"2009-03-03T18:51:08Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"On Sat, Feb 28, 2009 at 06:59:22PM +0100, Michael J Gruber wrote:\n> Josef Wolf venit, vidit, dixit 27.02.2009 23:05:\n> > On Fri, Feb 27, 2009 at 06:45:44PM +0100, Michael J Gruber wrote:\n> >> Josef Wolf venit, vidit, dixit 27.02.2009 18:12:\n> >>> On Wed, Feb 25, 2009 at 10:26:10AM +0100, Michael J Gruber wrote:\n> >>>> Josef Wolf venit, vidit, dixit 24.02.2009 23:34:\n> > \n> > [ ... ]\n> >>>   (cd git-svn-repos; git pull ../clone1)\n> >> Gives you 1-2-3-4\n> >>\n> >>>   (cd git-svn-repos; git svn rebase)\n> >> Does nothing here (but is good practice)\n> >>\n> >>>   (cd git-svn-repos; git svn dcommit)\n> >> Creates 2-3-4 on the svn side. *Then rebases* your master, which creates\n> >> 1-2'-3'-4' on master. Note that 2 is different from 2' (git-svn id).\n> > \n> > So the sha1 is not preserved when it goes through svn?\n> \n> No. Once your commits come back from svn through git-svn they have an\n> additional line in the commit. Also, the commit time time will be\n> different, and the author name might be depending on your name remapping.\n\nBut what prevents this new commit from being thrown back to svn again,\nand looping over and over again?\n\nFor some reason, I keep getting conflicts.  And the most annoying\npart is that even if I resolve the conflict in git-svn-repos, it\ngets propagated as a (spurious) conflict down to all the clones.\nHere's the recipe:\n\n(\n  set -ex\n\n  # create test directory\n  #\n  TESTDIR=`mktemp --tmpdir=. git-svn-hierarchy-test-XXXXXXXX`\n  rm -rf $TESTDIR\n  mkdir -p $TESTDIR\n  cd $TESTDIR\n\n  SUBVERSION_REPOS=file://`pwd`/subversion-repos\n\n  # create subversion repos with some history\n  #\n  svnadmin create subversion-repos\n  svn -m \"create standard layout\" mkdir \\\n      $SUBVERSION_REPOS/trunk \\\n      $SUBVERSION_REPOS/branches \\\n      $SUBVERSION_REPOS/tags\n  svn co $SUBVERSION_REPOS/trunk subversion-wc\n  echo change1 >>subversion-wc/test\n  svn add subversion-wc/test\n  svn ci -m \"commit 0\" subversion-wc\n\n  # create git-svn-repos\n  #\n  git svn init --stdlayout $SUBVERSION_REPOS git-svn-repos\n  (cd git-svn-repos; git svn fetch)\n\n  # create some clones\n  #\n  git clone git-svn-repos clone1\n  git clone git-svn-repos clone2\n  git clone git-svn-repos clone3\n\n  # work on clones, pull work into git-svn-repos when we're done\n  #\n  for clone in 1 2 3; do\n    (\n      cd clone$clone\n      git pull --rebase\n      for commit in 1 2 3; do\n        echo change $clone $commit >>test\n        git commit -a -m \"commit $clone $commit\"\n      done\n    )\n    (cd git-svn-repos; git pull --rebase ../clone$clone)\n  done\n\n  # commit from svn\n  #\n  ( cd subversion-wc; echo change s >>test; svn ci -m \"commit s\")\n\n  # git-svn-rebase gives us a conflict\n  #\n  ( cd git-svn-repos; git svn rebase )\n\n  # which we immediately resolve\n  #\n  (\n    cd git-svn-repos\n    (\n      echo change1\n      echo change s\n      echo change 1 1\n    ) >test\n    git add test\n    git rebase --continue\n  )\n\n  (cd git-svn-repos; git svn dcommit)\n\n  # Although we have resolved the conflict, spurious conflicts are\n  # propagated to the clones\n  #\n  for clone in 1 2 3; do\n    ( cd clone$clone ; git pull --rebase)\n  done\n)\n"},{"id":"106919","messageId":"eaa105840903031135o4cf72ed0oe3fffed69cb7ce03@mail.gmail.com","threadId":"17999","inReplyTo":"20090303185108.GA11278@raven.wolf.lan","subject":"Re: git-svn and repository hierarchy?","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2009-03-03T19:35:28Z","receivedAt":"2009-03-03T19:35:28Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Tue, Mar 3, 2009 at 1:51 PM, Josef Wolf wrote:\n>  # work on clones, pull work into git-svn-repos when we're done\n>  #\n>  for clone in 1 2 3; do\n>    (\n>      cd clone$clone\n>      git pull --rebase\n>      for commit in 1 2 3; do\n>        echo change $clone $commit >>test\n>        git commit -a -m \"commit $clone $commit\"\n>      done\n>    )\n>    (cd git-svn-repos; git pull --rebase ../clone$clone)\n>  done\n\nUm. This has each clone basing their commits on the work of some other\nclone. This line, specifically:\n\n>    (cd git-svn-repos; git pull --rebase ../clone$clone)\n\nbreaks the \"git-svn-repos only ever pulls from subversion\" model I\nsuggested elsewhere.\n\nAlso, this line says \"rebase my changes onto those of ../clone$clone\",\nwhich isn't what you want. It will end up rebasing svn commits that\nthe client didn't have on top of the client's commits, and will break\ngit-svn's index. Don't use --rebase here.\n\n>  # Although we have resolved the conflict, spurious conflicts are\n>  # propagated to the clones\n\n...and this is because you had clones all merge from each other (via\ngit-svn-repos) *before* the changes were in svn.\n\nWorse, since the git clients don't know that their work has been\nrebased, they can wind up conflicting with themselves too. Which is\nwhy I suggested \"git svn dcommit\" from each client, not from the\ncentral repository.\n\nThis can be made work if you do something more like (untested):\n    (cd git-svn-repos; git pull ../clone$clone topic-branch;\n    git svn dcommit)\n    (cd clone$clone; git checkout master; git pull;\n    have a human verify that changes to master are correct;\n    git branch -D topic-branch)\n\ninstead of\n\n>    (cd git-svn-repos; git pull --rebase ../clone$clone)\n\nie. throw away each topic branch as you push it to git-svn-repos, and\ntake the changes that have gone through git-svn back via a pull of\nmaster.\n\nBut that starts to look to me like more work for each clone than \"git\nsvn dcommit\" - YMMV, of course.\n\nPeter Harris\n"},{"id":"106935","messageId":"20090303223600.GB11278@raven.wolf.lan","threadId":"17999","inReplyTo":"eaa105840903031135o4cf72ed0oe3fffed69cb7ce03@mail.gmail.com","subject":"Re: git-svn and repository hierarchy?","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2009-03-03T22:36:00Z","receivedAt":"2009-03-03T22:36:00Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"Thanks for your answer, Peter!\n\nOn Tue, Mar 03, 2009 at 02:35:28PM -0500, Peter Harris wrote:\n> On Tue, Mar 3, 2009 at 1:51 PM, Josef Wolf wrote:\n> >  # work on clones, pull work into git-svn-repos when we're done\n> >  #\n> >  for clone in 1 2 3; do\n> >    (\n> >      cd clone$clone\n> >      git pull --rebase\n> >      for commit in 1 2 3; do\n> >        echo change $clone $commit >>test\n> >        git commit -a -m \"commit $clone $commit\"\n> >      done\n> >    )\n> >    (cd git-svn-repos; git pull --rebase ../clone$clone)\n> >  done\n> \n> Um. This has each clone basing their commits on the work of some other\n> clone. This line, specifically:\n> \n> >    (cd git-svn-repos; git pull --rebase ../clone$clone)\n> \n> breaks the \"git-svn-repos only ever pulls from subversion\" model I\n> suggested elsewhere.\n\nI'd rather not let every clone talk to subversion for several reasons.\nOne of them is that it is very inconvenient (e.g. the password has to\nbe entered several times for every commit).  After all, the whole point\nfor having git-svn-repos is for the clone to avoid working directly\nagainst the subversion repos.  If every clone works against subversion\nanyway, I can get rid of git-svn-repos as well.\n\n> Also, this line says \"rebase my changes onto those of ../clone$clone\",\n> which isn't what you want. It will end up rebasing svn commits that\n> the client didn't have on top of the client's commits, and will break\n> git-svn's index. Don't use --rebase here.\n\nHmm, I must have misunderstood Michael, then.  Wasn't he suggesting\nto rebase here?  Here's the citation:\n\n|>   (cd git-svn-repos; git pull ../clone1)  # if this line is executed,\n|\n|That's the problem. This creates a merge after which you 1-2-3-4 and\n|1-2'-3'-4' plus the merge of 4 and 4'.\n|\n|Instead, use git pull --rebase here. You don't want merges in the branch\n|from which you dcommit.\n\n> >  # Although we have resolved the conflict, spurious conflicts are\n> >  # propagated to the clones\n> \n> ...and this is because you had clones all merge from each other (via\n> git-svn-repos) *before* the changes were in svn.\n\nDoes that mean that the conflicts would disappear if I do\ngit-svn-rebase + git-svn-dcommit after every pull from a clone?\n\n> Worse, since the git clients don't know that their work has been\n> rebased, they can wind up conflicting with themselves too. Which is\n> why I suggested \"git svn dcommit\" from each client, not from the\n> central repository.\n> \n> This can be made work if you do something more like (untested):\n>     (cd git-svn-repos; git pull ../clone$clone topic-branch;\n>     git svn dcommit)\n>     (cd clone$clone; git checkout master; git pull;\n>     have a human verify that changes to master are correct;\n>     git branch -D topic-branch)\n> \n> instead of\n> \n> >    (cd git-svn-repos; git pull --rebase ../clone$clone)\n> \n> ie. throw away each topic branch as you push it to git-svn-repos, and\n> take the changes that have gone through git-svn back via a pull of\n> master.\n> \n> But that starts to look to me like more work for each clone than \"git\n> svn dcommit\" - YMMV, of course.\n\nIt might be more work.  But at least, I have the impression that I\nunderstand this workflow. ;-)\n"},{"id":"106938","messageId":"eaa105840903031618s5e0b6f24j64aade8d752fb11@mail.gmail.com","threadId":"17999","inReplyTo":"20090303223600.GB11278@raven.wolf.lan","subject":"Re: git-svn and repository hierarchy?","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2009-03-04T00:18:04Z","receivedAt":"2009-03-04T00:18:04Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Tue, Mar 3, 2009 at 5:36 PM, Josef Wolf wrote:\n>\n> I'd rather not let every clone talk to subversion for several reasons.\n> One of them is that it is very inconvenient (e.g. the password has to\n> be entered several times for every commit).\n\nSounds like subversion isn't properly caching your credentials, or\nyour admin is paranoid and turned off the svn credential cache. I\ncan't remember the last time I had to enter a password.\n\nOf course, git-svn-repo can't cache credentials, since it has to\nimpersonate different users. You are impersonating different users so\nthat the svn author field is correct, aren't you? But that shouldn't\nbe a problem for userN working on cloneN.\n\n>  After all, the whole point\n> for having git-svn-repos is for the clone to avoid working directly\n> against the subversion repos.  If every clone works against subversion\n> anyway, I can get rid of git-svn-repos as well.\n\nFrom my perspective, the main advantage of git-svn-repos is the inital\nclone. Subversion is way too slow to clone an entire project's history\n(days, vs minutes for git). Subsequent 'git pull --rebase's are faster\nthan 'git svn rebase's, too, although not by the same ratio (except\nfor large subtree moves, which really are that much faster).\n\n> On Tue, Mar 03, 2009 at 02:35:28PM -0500, Peter Harris wrote:\n>> Also, this line says \"rebase my changes onto those of ../clone$clone\",\n>> which isn't what you want. It will end up rebasing svn commits that\n>> the client didn't have on top of the client's commits, and will break\n>> git-svn's index. Don't use --rebase here.\n>\n> Hmm, I must have misunderstood Michael, then.  Wasn't he suggesting\n> to rebase here?  Here's the citation:\n>\n> |>   (cd git-svn-repos; git pull ../clone1)  # if this line is executed,\n> |\n> |That's the problem. This creates a merge after which you 1-2-3-4 and\n> |1-2'-3'-4' plus the merge of 4 and 4'.\n> |\n> |Instead, use git pull --rebase here. You don't want merges in the branch\n> |from which you dcommit.\n\nI think he meant to say \"git pull ../cloneN && git rebase trunk\".\n\n>> >  # Although we have resolved the conflict, spurious conflicts are\n>> >  # propagated to the clones\n>>\n>> ...and this is because you had clones all merge from each other (via\n>> git-svn-repos) *before* the changes were in svn.\n>\n> Does that mean that the conflicts would disappear if I do\n> git-svn-rebase + git-svn-dcommit after every pull from a clone?\n\nWell, 'disappear' is a strong word. \"cloneX\" has to be willing to\nreset to your branch if you have resolved any conflicts on behalf of\ncloneX. But the other cloneNs should not see those conflicts, at\nleast.\n\nNot to mention that it's not outside the realm of possibility that\nvarious cloneNs may be working with each other without involving you.\n\nPlus, there is a small window where clones may be pulling from each\nother, and will have to resolve the same conflicts you resolve during\nyour \"git svn dcommit\". I'm sure you've heard the saying \"Every\ncomputer science problem can be solved by adding a level of\nindirection.\" You could add a git-svn-stage that pulls from cloneN and\ndoes the dcommit (and then pushes to git-svn-repos, or lets\ngit-svn-repos do its own \"git svn fetch\"), leaving git-svn-repos clean\nfor cloneN to pull from...\n\nPeter Harris\n"},{"id":"107000","messageId":"20090304192752.GC11278@raven.wolf.lan","threadId":"17999","inReplyTo":"eaa105840903031618s5e0b6f24j64aade8d752fb11@mail.gmail.com","subject":"Re: git-svn and repository hierarchy?","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2009-03-04T19:27:52Z","receivedAt":"2009-03-04T19:27:52Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"On Tue, Mar 03, 2009 at 07:18:04PM -0500, Peter Harris wrote:\n> On Tue, Mar 3, 2009 at 5:36 PM, Josef Wolf wrote:\n> >\n> > I'd rather not let every clone talk to subversion for several reasons.\n> > One of them is that it is very inconvenient (e.g. the password has to\n> > be entered several times for every commit).\n> \n> Sounds like subversion isn't properly caching your credentials, or\n> your admin is paranoid and turned off the svn credential cache. I\n> can't remember the last time I had to enter a password.\n\nWhat credential cache are you talking about?  I don't know of any\nworth to be mentioned.  If you talk about \"store-passwords=yes\" in\nsubversion's config or about the .netrc file that has to be used for\ngit, you might be interested to read\nhttp://curl.haxx.se/docs/adv_20090303.html\nIf you know about another method, please tell me.\n\nBTW: The paranoid admin is myself.   ;-)\nBTW1: I know there's the possibility of client certificates.  But AFAIK,\n      there's no equivalent to ssh-agent, so it's pointless.\n\n> Of course, git-svn-repo can't cache credentials, since it has to\n> impersonate different users. You are impersonating different users so\n> that the svn author field is correct, aren't you? But that shouldn't\n> be a problem for userN working on cloneN.\n\nAh, that would have been one of my next questions (I don't like to start\nnew threads as long as old threads are on-going ;-)\nWithin svn, the author field seems to be correct (at least, it is\nidentical to those of the commits that were done directly to svn)\nBut when the commits come back to git, it is set to\n\"jw <jw@041dc122-08ea-11de-a769-bddc3e64b585>\" with the host-part being\nthe uuid of the svn-repo.\n\nAny ideas how to fix that?\n\nOh, and what happens if svn's rev-properties (commit log, author, date...)\nare changed?\n\n> >  After all, the whole point\n> > for having git-svn-repos is for the clone to avoid working directly\n> > against the subversion repos.  If every clone works against subversion\n> > anyway, I can get rid of git-svn-repos as well.\n> \n> From my perspective, the main advantage of git-svn-repos is the inital\n> clone. Subversion is way too slow to clone an entire project's history\n> (days, vs minutes for git). Subsequent 'git pull --rebase's are faster\n> than 'git svn rebase's, too, although not by the same ratio (except\n> for large subtree moves, which really are that much faster).\n\nOf course, initial clone is an argument.  But you do this exactly once\nper clone.  And you can do that unattended over the weekend.\n\nIn contrast, working directly against an svn repository is _very_\ntedious.  With a dozen commits pending, you have to enter your password\nabout 30..50 times in \"git svn dcommit\".  While you can run the initial\nclone unattended over the weekend, there's currently no (sensible) way \nto avoid this massive interactive password hammering.  And you have to\ndo that on every dcommit.\n\n> > On Tue, Mar 03, 2009 at 02:35:28PM -0500, Peter Harris wrote:\n> >> Also, this line says \"rebase my changes onto those of ../clone$clone\",\n> >> which isn't what you want. It will end up rebasing svn commits that\n> >> the client didn't have on top of the client's commits, and will break\n> >> git-svn's index. Don't use --rebase here.\n> >\n> > Hmm, I must have misunderstood Michael, then.  Wasn't he suggesting\n> > to rebase here?  Here's the citation:\n> >\n> > |>   (cd git-svn-repos; git pull ../clone1)  # if this line is executed,\n> > |\n> > |That's the problem. This creates a merge after which you 1-2-3-4 and\n> > |1-2'-3'-4' plus the merge of 4 and 4'.\n> > |\n> > |Instead, use git pull --rebase here. You don't want merges in the branch\n> > |from which you dcommit.\n> \n> I think he meant to say \"git pull ../cloneN && git rebase trunk\".\n\nDid you mean \"git pull ../cloneN && git rebase master\"?  There's no\ntrunk in git, AFAIK?\n\nSo here's my current idea about the work flow.  At the end of this mail,\nI've attached the whole test-script again.  But this time, I have\nextracted the main tasks\n  1. work on some clones\n  2. move commits from clone to subversion\n  3. move commits received from subversion to clone\nto make them more self-contained.  Ideally, those three tasks would\nbe packed into shell functions or something...\n\n\n  # 1. work on some clones\n  #\n  cd clone$clone\n  git checkout master\n  git pull --rebase                     # need rebase?\n  git checkout -b topic-branch\n  for commit in 1 2 3; do\n    echo change $clone $commit >>test\n    git commit -a -m \"commit $clone $commit\"\n  done\n\n\n\n  # 2. move commits from clone to subversion\n  #\n  cd git-svn-repos\n  git svn rebase\n  git pull ../clone$clone topic-branch   # need rebase?\n\n  # Check for conflict and pretend we have resolved it\n  grep change test >test.resolved\n  if diff test test.resolved ; then\n    rm test.resolved\n  else\n    mv test.resolved test\n    git add test\n    git commit -m \"merge\"\n  fi\n\n  git svn dcommit\n\n\n\n  # 3. move commits received from subversion to clone\n  #\n  cd clone$clone\n  git checkout master\n  git pull                               # need rebase?\n  git branch -D topic-branch\n\n\n\nThis work flow seems to generate a proper result and a sensible history.\nBut I am still not sure about when (and how) I have to rebase.  I have\nmarked the lines in question with \"#need rebase?\".\n\n\n#! /bin/sh\n\n(\n  set -x\n\n  # create test directory\n  #\n  TESTDIR=`mktemp --tmpdir=. git-svn-hierarchy-test-XXXXXXXX`\n  rm -rf $TESTDIR\n  mkdir -p $TESTDIR\n  cd $TESTDIR\n\n  SUBVERSION_REPOS=file://`pwd`/subversion-repos\n\n  # create subversion repos with some history\n  #\n  svnadmin create subversion-repos\n  svn -m \"create standard layout\" mkdir \\\n      $SUBVERSION_REPOS/trunk \\\n      $SUBVERSION_REPOS/branches \\\n      $SUBVERSION_REPOS/tags\n  svn co $SUBVERSION_REPOS/trunk subversion-wc\n  echo change1 >>subversion-wc/test\n  svn add subversion-wc/test\n  svn ci -m \"commit 0\" subversion-wc\n\n  # create git-svn-repos\n  #\n  git svn init --stdlayout $SUBVERSION_REPOS git-svn-repos\n  (cd git-svn-repos; git svn fetch)\n\n  # create some clones\n  #\n  git clone git-svn-repos clone1\n  git clone git-svn-repos clone2\n  git clone git-svn-repos clone3\n\n  for round in 1 2 3; do\n    for clone in 1 2 3; do\n\n     # work on clone\n     #\n     (\n       cd clone$clone\n       git checkout master\n       git pull --rebase\n       git checkout -b topic-branch\n       for commit in 1 2 3; do\n         echo change $round $clone $commit >>test\n         git commit -a -m \"commit $round $clone $commit\"\n       done\n     )\n\n     # move commits from clone to subversion\n     #\n     (\n       cd git-svn-repos\n       git svn rebase\n       git pull ../clone$clone topic-branch\n       grep change test >test.resolved\n\n       # Check for conflict and pretend we have resolved it\n       if diff test test.resolved ; then\n         rm test.resolved\n       else\n         mv test.resolved test\n         git add test\n         git commit -m \"merge\"\n       fi\n\n       git svn dcommit\n     )\n\n     # move commits from subversion to clone\n     (\n       cd clone$clone\n       git checkout master\n       git pull\n       git branch -D topic-branch\n     )\n    done\n\n    # commit from svn\n    #\n    (\n      cd subversion-wc\n      svn up\n      echo change $round s >>test\n      svn ci -m \"commit $round s\"\n    )\n\n  done\n)\n"},{"id":"107005","messageId":"eaa105840903041406k36088763w5a70fe1d7458dfb1@mail.gmail.com","threadId":"17999","inReplyTo":"20090304192752.GC11278@raven.wolf.lan","subject":"Re: git-svn and repository hierarchy?","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2009-03-04T22:06:06Z","receivedAt":"2009-03-04T22:06:06Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Wed, Mar 4, 2009 at 2:27 PM, Josef Wolf wrote:\n> On Tue, Mar 03, 2009 at 07:18:04PM -0500, Peter Harris wrote:\n>>\n>> Sounds like subversion isn't properly caching your credentials, or\n>> your admin is paranoid and turned off the svn credential cache. I\n>> can't remember the last time I had to enter a password.\n>\n> What credential cache are you talking about?  I don't know of any\n> worth to be mentioned.  If you talk about \"store-passwords=yes\" in\n> subversion's config\n\nYes, that's the one.\n\n> you might be interested to read\n> http://curl.haxx.se/docs/adv_20090303.html\n\nNot really, since I use svn:// :-)\n\n> BTW: The paranoid admin is myself.   ;-)\n> BTW1: I know there's the possibility of client certificates.  But AFAIK,\n>      there's no equivalent to ssh-agent, so it's pointless.\n\nI thought that this was already a part of svn, but it appears in the\n1.6 (not quite final yet) release notes: \"SSL client certificate\npassphrases can be stored in KWallet, GNOME Keyring, Mac OS Keychain,\na Windows CryptoAPI encrypted form or in plaintext form.\"\n\n> Within svn, the author field seems to be correct (at least, it is\n> identical to those of the commits that were done directly to svn)\n> But when the commits come back to git, it is set to\n> \"jw <jw@041dc122-08ea-11de-a769-bddc3e64b585>\" with the host-part being\n> the uuid of the svn-repo.\n>\n> Any ideas how to fix that?\n\n\"git help svn\" and look for \"--authors-file\", maybe. I don't use it\nmyself, so I'm afraid I can't help with that one. Personally, I don't\nmind user@uuid. Plus, user@uuid is so obviously different from git's\nstandard format that it is immediately obvious to me which commits are\nin svn, and which aren't, when running gitk.\n\n> Oh, and what happens if svn's rev-properties (commit log, author, date...)\n> are changed?\n\nToo late. git svn will ignore the change to the history, since git\nforces you to rewrite your entire history if any part changes. Cue\nstandard \"log messages should [not] be mutable\" flamewar.\n\nAh, here it is... <flamebait version>: Nothing happens. git will\ncorrectly store your *true* log/author/date, ignoring any and all\nattempts by malicious parties to destroy useful historical\ninformation.\n\nOf course, you're a paranoid admin, so you already have a\npre-revprop-change hook in your svn server that prevents\nlog/author/date changes. Right? ;-)\n\n> In contrast, working directly against an svn repository is _very_\n> tedious.\n\nTell me about it. Fortunately, we have git-svn to save us from the\ndefault svn client. ;-)\n(Sorry, couldn't resist pulling that one out of context)\n\n>  With a dozen commits pending, you have to enter your password\n> about 30..50 times in \"git svn dcommit\".\n\nMaybe svn 1.6 will fix that for you?\n\n>> I think he meant to say \"git pull ../cloneN && git rebase trunk\".\n>\n> Did you mean \"git pull ../cloneN && git rebase master\"?  There's no\n> trunk in git, AFAIK?\n\nIf a local branch isn't found, git will automatically look in remotes,\nso it will use remotes/trunk (the svn tracking branch). Modify to suit\nif you renamed remotes/trunk, of course.\n\n\"git branch -r\" to see the remote branches git-svn has set up for you.\n\nI'm pretty sure I didn't mean to suggest a no-op. Assuming you git\npull'd into master, \"git rebase master\" will be a no-op. rebase \"all\ncommits in (current branch) that aren't in master\" -> set operation\n(master - master = empty set) -> rebase (empty set) -> done.\n\n>  # 2. move commits from clone to subversion\n>  #\n>  cd git-svn-repos\n>  git svn rebase\n>  git pull ../clone$clone topic-branch   # need rebase?\n\nYeah, a \"git svn rebase -l\" after this line wouldn't hurt, and is\nsuggested by \"git help svn\". Or even reverse those two lines, to save\nadding a third:\n  git pull ../clone$clone topic-branch\n  git svn rebase\n\nAlternatively, you can avoid potential pull conflicts by using a\ntemporary branch to avoid the merge you are about to throw away with\nrebase -- remember that 'pull' is short for 'fetch && merge':\n\ngit fetch ../clone$clone topic-branch:scratch\ngit checkout scratch\ngit rebase trunk\ngit svn dcommit\ngit checkout master\ngit svn rebase -l # fast-forward master to where scratch is\ngit branch -d scratch\n\n...which should result in seeing only the rebase conflict(s). And\nought to work if cloneN's topic-branch is on a different svn branch\nfrom master (although you'd need to -D scratch instead of -d).\n\nPeter Harris\n"},{"id":"107085","messageId":"20090305180529.GD11278@raven.wolf.lan","threadId":"17999","inReplyTo":"eaa105840903041406k36088763w5a70fe1d7458dfb1@mail.gmail.com","subject":"Re: git-svn and repository hierarchy?","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2009-03-05T18:05:29Z","receivedAt":"2009-03-05T18:05:29Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"On Wed, Mar 04, 2009 at 05:06:06PM -0500, Peter Harris wrote:\n> On Wed, Mar 4, 2009 at 2:27 PM, Josef Wolf wrote:\n> > On Tue, Mar 03, 2009 at 07:18:04PM -0500, Peter Harris wrote:\n> >>\n> >> Sounds like subversion isn't properly caching your credentials, or\n> >> your admin is paranoid and turned off the svn credential cache. I\n> >> can't remember the last time I had to enter a password.\n> >\n> > What credential cache are you talking about?  I don't know of any\n> > worth to be mentioned.  If you talk about \"store-passwords=yes\" in\n> > subversion's config\n> \n> Yes, that's the one.\n> \n> > you might be interested to read\n> > http://curl.haxx.se/docs/adv_20090303.html\n> \n> Not really, since I use svn:// :-)\n\nDoesn't help ;-)  Many applications are using curllib, and all of them\ncan reveal your .netrc or subversion config.  For example, zypper and\napt use curllib, AFAIR.\n\n> > BTW: The paranoid admin is myself.   ;-)\n> > BTW1: I know there's the possibility of client certificates.  But AFAIK,\n> >      there's no equivalent to ssh-agent, so it's pointless.\n> \n> I thought that this was already a part of svn, but it appears in the\n> 1.6 (not quite final yet) release notes: \"SSL client certificate\n> passphrases can be stored in KWallet, GNOME Keyring, Mac OS Keychain,\n> a Windows CryptoAPI encrypted form or in plaintext form.\"\n\nUmmm, I always found it hard to find their changelog.  At least\nhttp://svn.collab.net/viewvc/svn/trunk/CHANGES?view=markup&pathrev=36138\ndon't mention those features.  Do you have a pointer?\n\n> > Within svn, the author field seems to be correct (at least, it is\n> > identical to those of the commits that were done directly to svn)\n> > But when the commits come back to git, it is set to\n> > \"jw <jw@041dc122-08ea-11de-a769-bddc3e64b585>\" with the host-part being\n> > the uuid of the svn-repo.\n> >\n> > Any ideas how to fix that?\n> \n> \"git help svn\" and look for \"--authors-file\", maybe. I don't use it\n> myself, so I'm afraid I can't help with that one.\n\nAh, I missed that.\n\n> > Oh, and what happens if svn's rev-properties (commit log, author, date...)\n> > are changed?\n> \n> Too late. git svn will ignore the change to the history, since git\n> forces you to rewrite your entire history if any part changes. Cue\n> standard \"log messages should [not] be mutable\" flamewar.\n> \n> Ah, here it is... <flamebait version>: Nothing happens. git will\n> correctly store your *true* log/author/date, ignoring any and all\n> attempts by malicious parties to destroy useful historical\n> information.\n> \n> Of course, you're a paranoid admin, so you already have a\n> pre-revprop-change hook in your svn server that prevents\n> log/author/date changes. Right? ;-)\n\nWell, actually it allows the changes for a very limited user group (that\nis: only me 8-).  While I agree that author/date should not be changed,\nI like to be able to fix silly typos in the log.  After all, we all do\ntypos now and then ;-)\n\n> > In contrast, working directly against an svn repository is _very_\n> > tedious.\n> \n> Tell me about it. Fortunately, we have git-svn to save us from the\n> default svn client. ;-)\n\nFortunately, the default client asks me for the password only once when\nI commit something.  git-svn is different here ;-)\n\n> (Sorry, couldn't resist pulling that one out of context)\n\n(Me too)\n\n> >  With a dozen commits pending, you have to enter your password\n> > about 30..50 times in \"git svn dcommit\".\n> \n> Maybe svn 1.6 will fix that for you?\n\nI don't think the problem is svn here.  Me tends to think git uses\ncurllib not in the way it was meant to be used.  And git-svn should\nreuse the existing connection instead of creating a new one for every\nbit it is going to transport.\n\n> >  # 2. move commits from clone to subversion\n> >  #\n> >  cd git-svn-repos\n> >  git svn rebase\n> >  git pull ../clone$clone topic-branch   # need rebase?\n> \n> Yeah, a \"git svn rebase -l\" after this line wouldn't hurt, and is\n> suggested by \"git help svn\".\n> \n> Or even reverse those two lines, to save adding a third:\n>   git pull ../clone$clone topic-branch\n>   git svn rebase\n\nWith this, I get twice as much conflicts (half of them being spurious).\nBut the history is linear on the clones, thus reflecting the svn history\nmore accurately, I guess.\n\n> Alternatively, you can avoid potential pull conflicts by using a\n> temporary branch to avoid the merge you are about to throw away with\n> rebase -- remember that 'pull' is short for 'fetch && merge':\n> \n> git fetch ../clone$clone topic-branch:scratch\n> git checkout scratch\n> git rebase trunk\n> git svn dcommit\n> git checkout master\n> git svn rebase -l # fast-forward master to where scratch is\n> git branch -d scratch\n> \n> ...which should result in seeing only the rebase conflict(s). And\n> ought to work if cloneN's topic-branch is on a different svn branch\n> from master (although you'd need to -D scratch instead of -d).\n\nI guess you meant \"git svn rebase trunk\", since dcommit complains about\noutdated transactions if \"git rebase trunk\" is used.\n\nOverall, this looks very good, since the history is linear and I get\nonly spurious conflicts, which I can get rid of with \"git rebase --skip\".\n\nMaybe there's room for more improvement:  Since the merge is done on a\nscratch branch anyway, why not letting the clones _push_ into branches\nwith random names: cloneX-`uuidgen` or something.  So the clones could\ndo the push whenever they have net access.  The actual merge can be done\ncompletely decoupled from the push operation.\n"},{"id":"107090","messageId":"eaa105840903051148s3515e8b7x9d7b8f9be12da735@mail.gmail.com","threadId":"17999","inReplyTo":"20090305180529.GD11278@raven.wolf.lan","subject":"Re: git-svn and repository hierarchy?","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2009-03-05T19:48:14Z","receivedAt":"2009-03-05T19:48:14Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Thu, Mar 5, 2009 at 1:05 PM, Josef Wolf wrote:\n> On Wed, Mar 04, 2009 at 05:06:06PM -0500, Peter Harris wrote:\n>>\n>> I thought that this was already a part of svn, but it appears in the\n>> 1.6 (not quite final yet) release notes: \"SSL client certificate\n>> passphrases can be stored in KWallet, GNOME Keyring, Mac OS Keychain,\n>> a Windows CryptoAPI encrypted form or in plaintext form.\"\n>\n> Ummm, I always found it hard to find their changelog.  At least\n> http://svn.collab.net/viewvc/svn/trunk/CHANGES?view=markup&pathrev=36138\n> don't mention those features.  Do you have a pointer?\n\nhttp://subversion.tigris.org/svn_1.6_releasenotes.html#auth-related-improvements\n\n>> Of course, you're a paranoid admin, so you already have a\n>> pre-revprop-change hook in your svn server that prevents\n>> log/author/date changes. Right? ;-)\n>\n> Well, actually it allows the changes for a very limited user group (that\n> is: only me 8-).  While I agree that author/date should not be changed,\n> I like to be able to fix silly typos in the log.  After all, we all do\n> typos now and then ;-)\n\nTrue, but in my experience it happens considerably less often with\ngit. I find and fix most of my typos when reviewing my change-set\nbefore doing a \"git push\" or \"git svn dcommit\".\n\n> Maybe there's room for more improvement:  Since the merge is done on a\n> scratch branch anyway, why not letting the clones _push_ into branches\n> with random names: cloneX-`uuidgen` or something.  So the clones could\n> do the push whenever they have net access.  The actual merge can be done\n> completely decoupled from the push operation.\n\nIndeed. Or even not-so-random names, such as cloneX/topic-name if you prefer.\n\nPeter Harris\n"},{"id":"107220","messageId":"20090306161026.GA14554@raven.wolf.lan","threadId":"17999","inReplyTo":"eaa105840903051148s3515e8b7x9d7b8f9be12da735@mail.gmail.com","subject":"Re: git-svn and repository hierarchy?","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2009-03-06T16:10:26Z","receivedAt":"2009-03-06T16:10:26Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"On Thu, Mar 05, 2009 at 02:48:14PM -0500, Peter Harris wrote:\n> On Thu, Mar 5, 2009 at 1:05 PM, Josef Wolf wrote:\n> >\n> > Well, actually it allows the changes for a very limited user group (that\n> > is: only me 8-).  While I agree that author/date should not be changed,\n> > I like to be able to fix silly typos in the log.  After all, we all do\n> > typos now and then ;-)\n> \n> True, but in my experience it happens considerably less often with\n> git. I find and fix most of my typos when reviewing my change-set\n> before doing a \"git push\" or \"git svn dcommit\".\n\nSo you are rewriting yourself but not accept rewrites by svn ;-)\n\n> > Maybe there's room for more improvement:  Since the merge is done on a\n> > scratch branch anyway, why not letting the clones _push_ into branches\n> > with random names: cloneX-`uuidgen` or something.  So the clones could\n> > do the push whenever they have net access.  The actual merge can be done\n> > completely decoupled from the push operation.\n> \n> Indeed. Or even not-so-random names, such as cloneX/topic-name if you\n> prefer.\n\nThat would have the risk of multiple clones pushing to the same branch.\nI am not sure I am prepared to resolve such conflicts (yet).  But you\nare right, the branch name should contain the topic-name.  So here's my\ncurrent favorite of the workflow:\n\n\n     # work on clone\n     #\n     (\n       cd clone$clone\n\n       # first move commits from subversion to clone\n       #\n       git checkout master\n       git pull --rebase\n\n       # do some work\n       #\n       git checkout -b topic-branch\n       for commit in 1 2 3; do\n         echo change $clone $commit >>test\n         git commit -a -m \"commit $clone $commit\"\n       done\n\n       # push the work\n       #\n       git push ../git-svn-repos topic-branch:clone-topic-branch-`uuidgen`\n       git checkout master\n       git branch -D topic-branch\n     )\n\n\n\n     # Integrate commits from clones an move them to subversion\n     #\n     (\n       cd git-svn-repos\n       for scratch in `git branch | grep ' clone-'` ; do\n\n         # merge client's work\n         #\n         git checkout $scratch\n         git svn rebase trunk\n\n         # resolve possible conflicts\n         #\n         grep change test >test.resolved\n         if diff test test.resolved ; then\n             rm test.resolved\n         else\n             mv test.resolved test\n             git add test\n             git commit -m \"merge\"\n             git rebase --skip\n         fi\n\n         # sync with svn repository\n         #\n         git svn dcommit\n         git checkout master\n         git svn rebase -l     # fast-forward master to where scratch is\n\n         # clean up\n         #\n         git branch -d $scratch\n       done\n      )\n\n\n\nDoes that look sane?\n\nThe benefit is that work on clones and work on git-svn-repos is\ndecoupled.\n"},{"id":"107228","messageId":"eaa105840903060858g5b8f31bpb9a59d563835a9d5@mail.gmail.com","threadId":"17999","inReplyTo":"20090306161026.GA14554@raven.wolf.lan","subject":"Re: git-svn and repository hierarchy?","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2009-03-06T16:58:36Z","receivedAt":"2009-03-06T16:58:36Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Fri, Mar 6, 2009 at 11:10 AM, Josef Wolf wrote:\n> On Thu, Mar 05, 2009 at 02:48:14PM -0500, Peter Harris wrote:\n>>\n>> True, but in my experience it happens considerably less often with\n>> git. I find and fix most of my typos when reviewing my change-set\n>> before doing a \"git push\" or \"git svn dcommit\".\n>\n> So you are rewriting yourself but not accept rewrites by svn ;-)\n\nNo, I am not rewriting myself *after I publish*. I see the smiley, but\nI think you missed the point.\n\n\"git push\" or \"svn ci\" is the end of the rewrites.\n\nThe critical difference is that I can easily manage an entire\nunpublished patch series in git. I cannot in svn (without 3rd party\ntools such as quilt or git-svn, anyway). So in svn if I notice a typo\nnear the beginning of a patch series as I am publishing the last of\nthe series, I'm screwed.\n\n>> Indeed. Or even not-so-random names, such as cloneX/topic-name if you\n>> prefer.\n>\n> That would have the risk of multiple clones pushing to the same branch.\n\nOnly if cloneX pushes to cloneY/topic-name. Does each clone not have a\nunique name?\n\n> Does that look sane?\n\nNo. But it doesn't look any more insane than any other workflow\ninvolving Subversion that I can think of. :-)\n\nPeter Harris\n"},{"id":"107234","messageId":"20090306175724.GB14554@raven.wolf.lan","threadId":"17999","inReplyTo":"eaa105840903060858g5b8f31bpb9a59d563835a9d5@mail.gmail.com","subject":"Re: git-svn and repository hierarchy?","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2009-03-06T17:57:24Z","receivedAt":"2009-03-06T17:57:24Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"On Fri, Mar 06, 2009 at 11:58:36AM -0500, Peter Harris wrote:\n> On Fri, Mar 6, 2009 at 11:10 AM, Josef Wolf wrote:\n> > On Thu, Mar 05, 2009 at 02:48:14PM -0500, Peter Harris wrote:\n> >>\n> >> True, but in my experience it happens considerably less often with\n> >> git. I find and fix most of my typos when reviewing my change-set\n> >> before doing a \"git push\" or \"git svn dcommit\".\n> >\n> > So you are rewriting yourself but not accept rewrites by svn ;-)\n> \n> No, I am not rewriting myself *after I publish*. I see the smiley, but\n> I think you missed the point.\n> \n> \"git push\" or \"svn ci\" is the end of the rewrites.\n\nI see.  Thanks for the clarification!\n\n> >> Indeed. Or even not-so-random names, such as cloneX/topic-name if you\n> >> prefer.\n> >\n> > That would have the risk of multiple clones pushing to the same branch.\n> \n> Only if cloneX pushes to cloneY/topic-name. Does each clone not have a\n> unique name?\n\nI'd rather not rely on the clones having unique names.\n\n> > Does that look sane?\n> \n> No. But it doesn't look any more insane than any other workflow\n> involving Subversion that I can think of. :-)\n\nOK, I parse that as \"there's not much room for improvement\" :-)\n\nThanks for your great help!  I have learned a lot in this thread!\n"},{"id":"107403","messageId":"20090308213340.6784e685@schatten","threadId":"17999","inReplyTo":"20090306161026.GA14554@raven.wolf.lan","subject":"Re: git-svn and repository hierarchy?","fromName":"Florian Mickler","fromEmail":"florian@mickler.org","sentAt":"2009-03-08T20:33:40Z","receivedAt":"2009-03-08T20:33:40Z","isPatch":false,"sender":{"key":"florian@mickler.org","avatar":null},"body":"On Fri, 6 Mar 2009 17:10:26 +0100\nJosef Wolf <jw@raven.inka.de> wrote:\n\n> On Thu, Mar 05, 2009 at 02:48:14PM -0500, Peter Harris wrote:\n> > On Thu, Mar 5, 2009 at 1:05 PM, Josef Wolf wrote:\n> > >\n> > > Well, actually it allows the changes for a very limited user\n> > > group (that is: only me 8-).  While I agree that author/date\n> > > should not be changed, I like to be able to fix silly typos in\n> > > the log.  After all, we all do typos now and then ;-)\n> > \n> > True, but in my experience it happens considerably less often with\n> > git. I find and fix most of my typos when reviewing my change-set\n> > before doing a \"git push\" or \"git svn dcommit\".\n> \n> So you are rewriting yourself but not accept rewrites by svn ;-)\n\nthe thing is: with git you don't ''rewrite history''. \nyou create a completely new history. that is because the\nsha1-descriptions includes the meta-data.\n\nthat means, even if you want, you can't change ''published'' history.\nbecause the history is unique'ly identified by the topmost sha-1. \nif smth changes underneath the topmost sha-1 you have to rebase all\nyour other changes on the new sha-1 and thus altering them. \n\nthat is why the dcommitt'ed&svn-rebased changes have different sha-1s\nand all your clone's work needs to be rebased onto the newly altered\ncommitts.\n\n\nSincerely,\n\nFlorian\n\n\n"}]}