{"thread":{"id":"19165","subject":"git-svn: ignoring a bogus svn revision ?","startedAt":"2009-05-03T19:24:03Z","lastAt":"2009-05-04T07:28:03Z","messageCount":2,"participants":["Nicolas Noble","Deskin Miller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"112929","messageId":"a70244740905031224j6b215bcfxfe11bf5ae84c70fd@mail.gmail.com","threadId":"19165","inReplyTo":null,"subject":"git-svn: ignoring a bogus svn revision ?","fromName":"Nicolas Noble","fromEmail":"pixel.nobis@gmail.com","sentAt":"2009-05-03T19:24:03Z","receivedAt":"2009-05-03T19:24:03Z","isPatch":false,"sender":{"key":"pixel.nobis@gmail.com","avatar":null},"body":"Hello,\n\n  I'm a frantic user of git-svn at work, as my company uses SVN as a\nSCM for all of our projects. I've been very happily using git-svn over\nour repositories since quite some time, and I think I managed to\nconvert a couple of colleagues by doing so.\n\n  But now I'm facing an interesting issue. Our biggest repository has\nover 102600 revisions, and initializing from scratch the git\nrepository up to this revision takes approximately 2 days of computer\nwork. The trouble begins with revision 102601... Up so far the\nrepository was in a perfect shape, and no one did any huge mistake. On\nrevision 102601 however, someone branched... /. Not /trunk, but /,\nwhich means the whole nine yards, containing tags, branches, and\ntrunk.\n\n  So I'm stuck with this:\n\nrepository-up-to-102600$ git branch -r | wc -l\n1824\n\n  And when I issue a git-svn fetch --no-follow-parent --revision\n102601, git-svn starts trying to fetch all of these 1824 branches and\ntag, obviously. I had to add the --no-follow-parent otherwise git-svn\nwould just go nuts. Now if it wasn't for the loosy svn server\ndisconnecting me after 2 or 3 days of work trying to check out this\nbranch, git-svn would probably manage to get over it. But the server\ncan't keep up it seems, and I eventually get disconnected, which means\nI have to do it all over again.\n\n  Of course, this svn commit is undeniably bogus, and no one will ever\nbe able to check it out and work on it for real. However, this doesn't\ndisrupt the usual course of work for other SVN users, but just\nprevents anyone from using git-svn ever again on this repository.\n\n  I've tried to look into how to remove/amend this svn revision\ndirectly onto the server, but even if some documentation was telling\nme how to do so (which isn't the case), our IS crew is just too\nstubborn, and fills my requests back with \"Please use a SVN client\nsupported by the IS crew; you can find links on this page...\". I'm\nstill going to try to go through this path though, as I feel this is\nprobably the right thing to do, (apart holding my boss hostage in his\noffice until they finally decide to switch over to git completely, and\nstop using a piece of software that allows you to push bogus commits)\n\n  So on the other hand, I'm looking at how git-svn works, and I'm\ntrying to jump around this utterly bogus svn revision. I haven't found\nany information at all about how I could skip this revision, and even\nthough I'm all willing to make some tests on the git repository itself\nby tweaking it, I'd hate to leave it in a broken state that would\nexplode in my hands several weeks/month later. Thus I think I'd better\nask the authors directly, in order to know how I could achieve that in\na way that isn't too disruptive.\n\n  Thanks!\n\n  -- Nicolas Noble\n"},{"id":"112961","messageId":"86d4c5e00905040028v1136e49cn5478e6a50020ab0d@mail.gmail.com","threadId":"19165","inReplyTo":"a70244740905031224j6b215bcfxfe11bf5ae84c70fd@mail.gmail.com","subject":"Re: git-svn: ignoring a bogus svn revision ?","fromName":"Deskin Miller","fromEmail":"deskinm@umich.edu","sentAt":"2009-05-04T07:28:03Z","receivedAt":"2009-05-04T07:28:03Z","isPatch":false,"sender":{"key":"deskinm@umich.edu","avatar":"https://gravatar.com/avatar/d340a0e612cdf0a79535c71863c0b4c535e9aba63b42032226ae903e638b64f9?d=mp&s=160"},"body":"On Sun, May 3, 2009 at 12:24, Nicolas Noble <pixel.nobis@gmail.com> wrote:\n> Hello,\n>\n>  I'm a frantic user of git-svn at work, as my company uses SVN as a\n> SCM for all of our projects. I've been very happily using git-svn over\n> our repositories since quite some time, and I think I managed to\n> convert a couple of colleagues by doing so.\n>\n>  But now I'm facing an interesting issue. Our biggest repository has\n> over 102600 revisions, and initializing from scratch the git\n> repository up to this revision takes approximately 2 days of computer\n> work. The trouble begins with revision 102601... Up so far the\n> repository was in a perfect shape, and no one did any huge mistake. On\n> revision 102601 however, someone branched... /. Not /trunk, but /,\n> which means the whole nine yards, containing tags, branches, and\n> trunk.\n>\n>  So I'm stuck with this:\n>\n> repository-up-to-102600$ git branch -r | wc -l\n> 1824\n>\n>  And when I issue a git-svn fetch --no-follow-parent --revision\n> 102601, git-svn starts trying to fetch all of these 1824 branches and\n> tag, obviously. I had to add the --no-follow-parent otherwise git-svn\n> would just go nuts. Now if it wasn't for the loosy svn server\n> disconnecting me after 2 or 3 days of work trying to check out this\n> branch, git-svn would probably manage to get over it. But the server\n> can't keep up it seems, and I eventually get disconnected, which means\n> I have to do it all over again.\n>\n>  Of course, this svn commit is undeniably bogus, and no one will ever\n> be able to check it out and work on it for real. However, this doesn't\n> disrupt the usual course of work for other SVN users, but just\n> prevents anyone from using git-svn ever again on this repository.\n>\n>  I've tried to look into how to remove/amend this svn revision\n> directly onto the server, but even if some documentation was telling\n> me how to do so (which isn't the case), our IS crew is just too\n> stubborn, and fills my requests back with \"Please use a SVN client\n> supported by the IS crew; you can find links on this page...\". I'm\n> still going to try to go through this path though, as I feel this is\n> probably the right thing to do, (apart holding my boss hostage in his\n> office until they finally decide to switch over to git completely, and\n> stop using a piece of software that allows you to push bogus commits)\n>\n>  So on the other hand, I'm looking at how git-svn works, and I'm\n> trying to jump around this utterly bogus svn revision. I haven't found\n> any information at all about how I could skip this revision, and even\n> though I'm all willing to make some tests on the git repository itself\n> by tweaking it, I'd hate to leave it in a broken state that would\n> explode in my hands several weeks/month later. Thus I think I'd better\n> ask the authors directly, in order to know how I could achieve that in\n> a way that isn't too disruptive.\n\nI should probably say now that it's a good idea to back up your git\nrepository, by making a plain old directory copy, before trying any of\nthe stuff here; especially given that you're up to 100000 revisions, I\nwouldn't want you to have to wait two more days because I gave bad\nadvice.  Using cp is necessary to back up the metadata related to\ngit-svn which isn't transferred through a normal git clone.\n\nFortunately there's a relatively painless way to avoid the bad svn\nrevision, by using the -r$m:$n flag to git svn fetch, where $m and $n\nare integers.  If you do e.g.\n\n$ git svn fetch -r1:102600\n$ git svn fetch -r102602:HEAD\n\ngit-svn will happily skip over the bad revision 102601, and fetch\n102602 up to the latest svn revision, creating a history with the same\ntree content but skipping that commit.  From a git mindset, the\ngeneral case of this is very much like squashing several commits in to\none- the resultant tree is the same but some history has been omitted\nor 'cleaned up'.  Note that HEAD on the command line here is *not* the\nsame as git's HEAD; it is rather an svn keyword meaning the latest\nrevision number.\n\nThere are potentially two complications with this approach; neither is\nvery serious, and the bottom line is that you might have to continue\ndoing a command like the above to fetch, with an explicit revision\nrange, instead of omitting them entirely.\n\nThe first complication is that your svn repository will most likely\nrevert commit 102601 by deleting the offending branch in a later\ncommit.  In this case, you have not one, but two bad revisions to\navoid.  Not to worry- one can simply grab the range in between the two\nbad commits as illustrated above; suppose the revert happened in\ncommit 102644:\n\n$ git svn fetch -r1:102600 # up to bad branch creation\n$ git svn fetch -r102602:102643 # between bad create and delete\n$ git svn fetch -r102645:HEAD # up to most recent\n\nNote that the revision numbers specified with -r are inclusive on both\nends, that is, you'll get commits corresponding to both the low and\nhigh revision number (if the commits are interesting to your view of\nsvn).  Additionally, you should be able to see how to generalise this\nfrom here, for n arbitrary bad commits.\n\nThe second complication, and I only mention this because I can't test\nthe behaviour right now, is that even after fetching up past the bad\nrevision(s) to svn HEAD, you may need to continue to specify an\nexplicit revision range to avoid the bad commit(s).  This is because\ngit-svn tries to fetch from the revision of the latest commit it\nobtained from svn when you don't specify an explicit revision range.\nConsequently, if none of the revisions after the bad commit(s) were\ninteresting to you (perhaps they were on other projects in the same\nsvn repo, or in branches you aren't interested in), then when you go\nto run git svn fetch again, your repository hasn't 'recorded' any\nhistory which omits the bad commits, since there hasn't been anything\nto fetch yet.  In this case, you need to continue to use the explicit\nrevision numbers, as appropriate, until you have actual commits\ncorresponding to later revisions than the bad ones.\n\nActually, it is more strict than that- to be safe, use the explicit\nrevision numbers until your git view of svn trunk has a commit after\nthe bad revision number(s).  In other words, it's not enough for some\nbranches to get commits which come after the bad revision; until trunk\nmoves forward, you should continue using the explicit revision range.\nIt's possible I'm mistaken on this necessity, but better safe than\nsorry; if you want to experiment on your repository, feel free.\n\nOther things to consider when doing this, perhaps more for others\nreading along: I strongly discourage doing this for anything but\npathological cases like yours; that is, don't be tempted to tidy up\nsvn history by skipping commits, perhaps saying to yourself 'but the\ntrees end up the same, and those svn users probably would've squashed\nthese commits themselves if only they were using a DVCS'.  You will\nregret it.  Doing so would be akin to cloning a public git repository,\nsquashing already-public commits together, and expecting others to\nfollow how your clone and the origin are related.  Skipping svn\nrevisions should rather be viewed as a nuclear option, used only when\nthere's really truly no other way to progress, like your case.\n\nLet me say it again, because I've seen plenty of people on IRC who\nthink that git-svn is hanging, when it's not, and I don't want them to\nthink that the way around this supposed hang is to skip the nasty\nrevision: Don't do it unless you're absolutely sure you need to.\n\nHope that helps,\n\nDeskin Miller\n"}]}