{"thread":{"id":"19923","subject":"git-svn seems confused about current HEAD","startedAt":"2009-06-25T00:00:44Z","lastAt":"2009-07-03T17:43:05Z","messageCount":3,"participants":["tom fogal","Eric Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"116896","messageId":"auto-000019790488@sci.utah.edu","threadId":"19923","inReplyTo":null,"subject":"git-svn seems confused about current HEAD","fromName":"tom fogal","fromEmail":"tfogal@alumni.unh.edu","sentAt":"2009-06-25T00:00:44Z","receivedAt":"2009-06-25T00:00:44Z","isPatch":false,"sender":{"key":"tfogal@alumni.unh.edu","avatar":"https://gravatar.com/avatar/a2f71bfbe12b2b73cad0be2386d554aa403fff7a89df2f79e812c97c7eab0498?d=mp&s=160"},"body":"I've got a repository that git-svn won't grab the most recent commits\nfor:\n\n tf@shigeru tuvok ~/sw/bin/git svn find-rev HEAD\n 1164\n tf@shigeru tuvok ~/sw/bin/git svn fetch\n tf@shigeru tuvok ~/sw/bin/git --version\n git version 1.6.3.3\n\nThe repository is actually at revision 1184. It's browsable online:\n\n https://gforge.sci.utah.edu/gf/project/Tuvok/scmsvn/\n\nand publicly clonable:\n\n https://gforge.sci.utah.edu/svn/Tuvok\n\nInterestingly, 1165 is also a commit which contains a string which\nis not representable in 8bit ASCII in the commit log. This is very\nlikely to be the only such commit in the repository's history. After\ncloning, setting i18n.commitencoding and i18n.logoutputencoding to\nISO-8859-1 and then trying another `git svn fetch' does not seem to\nhave any effect.\n\nRevisions 1166-1169 actually correspond to some commits I did to split\na particular directory of that repository into another repository, and\nthen add an svn:external for it. I did that via an svn checkout.\n\nThis is actually a `secondary' clone. In the clone I use to do daily\nwork, I have somehow magically convinced my git repository that commits\n116[56] do not exist. A contiguous snippet from `git log':\n\n commit 351dedb982af09e170b17001340208af46b197b5\n Author: tfogal \n Date: Sat Jun 6 20:42:11 2009 +0000\n\n Use external `scio' repository.\n\n git-svn-id: https://gforge.sci.utah.edu/svn/Tuvok@1167\n c36c8488-0289-0348-9b64-b301f74bd9a7\n\n commit 401493d9175ebdb3c62d6524c701944f208aba94\n Author: tfogal \n Date: Fri Jun 5 22:54:48 2009 +0000\n\n no newline at EOF issue.\n\n git-svn-id: https://gforge.sci.utah.edu/svn/Tuvok@1164\n c36c8488-0289-0348-9b64-b301f74bd9a7\n\nI have no idea how I managed to do that, but it seems to have done\nthe trick; I haven't noticed any issues with that clone, and I've\napparently been working with it for a couple weeks now.\n\nIs there a known workaround for this issue (or, how did I manage to\n`ignore' those commits in my initial repo)?\n\nThanks,\n\n-tom\n"},{"id":"117346","messageId":"20090702075438.GA11119@dcvr.yhbt.net","threadId":"19923","inReplyTo":"auto-000019790488@sci.utah.edu","subject":"Re: git-svn seems confused about current HEAD","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2009-07-02T07:54:38Z","receivedAt":"2009-07-02T07:54:38Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"tom fogal wrote:\n> I've got a repository that git-svn won't grab the most recent commits\n> for:\n> \n> tf@shigeru tuvok ~/sw/bin/git svn find-rev HEAD\n> 1164\n> tf@shigeru tuvok ~/sw/bin/git svn fetch\n> tf@shigeru tuvok ~/sw/bin/git --version\n> git version 1.6.3.3\n> \n> The repository is actually at revision 1184. It's browsable online:\n> \n> https://gforge.sci.utah.edu/gf/project/Tuvok/scmsvn/\n> \n> and publicly clonable:\n> \n> https://gforge.sci.utah.edu/svn/Tuvok\n> \n> Interestingly, 1165 is also a commit which contains a string which\n> is not representable in 8bit ASCII in the commit log. This is very\n> likely to be the only such commit in the repository's history. After\n> cloning, setting i18n.commitencoding and i18n.logoutputencoding to\n> ISO-8859-1 and then trying another `git svn fetch' does not seem to\n> have any effect.\n\nWow, \"svn log\" seems to croak on 1165, too. How did you manage that? I\nguess SVN servers don't check for UTF-8 validity at all in the\ncommits...\n\nI would get your SVN administrator to propedit the r1165 log entry\nso people can see it in the future. Basically git svn relies\non the library version of \"svn log\", so if \"svn log\" fails, then\ngit svn usually has no chance of getting those revisions.\n\n> Revisions 1166-1169 actually correspond to some commits I did to split\n> a particular directory of that repository into another repository, and\n> then add an svn:external for it. I did that via an svn checkout.\n> \n> This is actually a `secondary' clone. In the clone I use to do daily\n> work, I have somehow magically convinced my git repository that commits\n> 116[56] do not exist. A contiguous snippet from `git log':\n> \n> commit 351dedb982af09e170b17001340208af46b197b5\n> Author: tfogal \n> Date: Sat Jun 6 20:42:11 2009 +0000\n> \n> Use external `scio' repository.\n> \n> git-svn-id: https://gforge.sci.utah.edu/svn/Tuvok@1167\n> c36c8488-0289-0348-9b64-b301f74bd9a7\n> \n> commit 401493d9175ebdb3c62d6524c701944f208aba94\n> Author: tfogal \n> Date: Fri Jun 5 22:54:48 2009 +0000\n> \n> no newline at EOF issue.\n> \n> git-svn-id: https://gforge.sci.utah.edu/svn/Tuvok@1164\n> c36c8488-0289-0348-9b64-b301f74bd9a7\n> \n> I have no idea how I managed to do that, but it seems to have done\n> the trick; I haven't noticed any issues with that clone, and I've\n> apparently been working with it for a couple weeks now.\n\nI think one of your clones worked for you because 1166 was the latest\nrevision for you when you ran \"git svn fetch\", so the next time you ran\n\"git svn fetch\" it would've started exactly at 1166.\n\n> Is there a known workaround for this issue (or, how did I manage to\n> `ignore' those commits in my initial repo)?\n\nHere's what I did when the initial clone got stuck at 1164:\n\n# kill the revmap, it caches the max revision to start scanning\n# (if you're using using noMetadata you'll need to use dd or a\n# a hex editor and delete the last 24 bytes instead.\n$ rm .git/svn/git-svn/.rev_map.c36c8488-0289-0348-9b64-b301f74bd9a7\n\n# Instead of attempting to scan starting at 1164, start at 1166 instead\n$ git svn fetch -r1166:HEAD\n\nI was stuck on this problem for a while, too... 1165 seems\nunrepresentable at the moment because of the log message.\n\n-- \nEric Wong\n"},{"id":"117422","messageId":"auto-000019869879@sci.utah.edu","threadId":"19923","inReplyTo":"20090702075438.GA11119@dcvr.yhbt.net","subject":"Re: git-svn seems confused about current HEAD","fromName":"tom fogal","fromEmail":"tfogal@alumni.unh.edu","sentAt":"2009-07-03T17:43:05Z","receivedAt":"2009-07-03T17:43:05Z","isPatch":false,"sender":{"key":"tfogal@alumni.unh.edu","avatar":"https://gravatar.com/avatar/a2f71bfbe12b2b73cad0be2386d554aa403fff7a89df2f79e812c97c7eab0498?d=mp&s=160"},"body":"Hi all, just wanted to ACK and confirm that the recommended actions\nwere sound.\n\nEric Wong writes:\n> tom fogal wrote:\n> > I've got a repository that git-svn won't grab the most recent commits\n> > for:\n> > \n> > tf@shigeru tuvok ~/sw/bin/git svn find-rev HEAD\n> > 1164\n> > tf@shigeru tuvok ~/sw/bin/git svn fetch\n> > tf@shigeru tuvok ~/sw/bin/git --version\n> > git version 1.6.3.3\n> > \n> > The repository is actually at revision 1184.\n> >\n> > Interestingly, 1165 is also a commit which contains a string which\n> > is not representable in 8bit ASCII in the commit log.\n> \n> Wow, \"svn log\" seems to croak on 1165, too. How did you manage that? I\n> guess SVN servers don't check for UTF-8 validity at all in the\n> commits...\n\n*shrug*, I just copy-and-pasted a contributor's name into the log. I\nthink in the future, I'll leave their names in the code instead of the\nlog :)\n\n> I would get your SVN administrator to propedit the r1165 log entry\n> so people can see it in the future. Basically git svn relies on the\n> library version of \"svn log\", so if \"svn log\" fails, then git svn\n> usually has no chance of getting those revisions.\n\nI think Eric was referring to `svnadmin setlog' here. We've done that\nand everything seems to be working well.\n\nI'm slightly worried that I've rewritten history behind git's back\n-- I'm likening it to rebasing an upstream after pulling from it --\nbut everything seems okay so far without any gymnastics downstream.\nPerhaps it's not an issue because only a log message, and not actual\ncode, has changed. *shrug*, for my case, re-cloning wouldn't be a\ndisaster anyway.\n\n> > Is there a known workaround for this issue (or, how did I manage to\n> > `ignore' those commits in my initial repo)?\n> \n> Here's what I did when the initial clone got stuck at 1164:\n[snip]\n\nThanks much for the help!\n\n-tom\n"}]}