{"thread":{"id":"24559","subject":"[GSoC update] git-remote-svn: Week 13","startedAt":"2010-07-28T16:26:29Z","lastAt":"2010-07-28T16:26:29Z","messageCount":1,"participants":["Ramkumar Ramachandra"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"146633","messageId":"20100728162627.GA31912@kytes","threadId":"24559","inReplyTo":null,"subject":"[GSoC update] git-remote-svn: Week 13","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-07-28T16:26:29Z","receivedAt":"2010-07-28T16:26:29Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nIt looks like I've hit a wall with the dumping functionality in\nsvnrdump- it's merged in cleanly with tests to show where it passes\nalong with others that highlight the places that it fails. We've\ndetermined that it cannot do better until the underlying\ninfrastructure (RA layer) is improved, so I've finally stopped working\non this. The dumpfile that it produces is completely valid, but\ndoesn't match exactly with the dumpfile that `svnadmin dump`\nproduces. Since Junio has recommended that I don't get svnrdump merged\ninto git.git, I'll maintain an out-of-tree version that compiles\nagainst Subversion 1.6; however, git-remote-svn will have to spawn the\nexecutable instead of just including a header and using the API that\nit exposes atleast until the next Subversion release.\n\nWith my subcommand patch merged in, I've removed my svnrload branch\nand started working on the \"load\" subcommand directly in trunk. The\nfunctionality I expect to implement is \"svnrdump load\" -- it'll read a\ndumpfile from stdin and commit the revisions that it represents to a\nspecified remote repository. Unfortunately, this is quite non-trivial,\nand I'm working *really* hard to try and finish this before the end of\nthe SoC term. I've found a tool called svnmucc in the trunk that I can\nuse as reference while writing this.\n\nsvn-fe itself is in excellent shape in `pu` (thanks to Jonathan's\nextensive cleanup and re-roll it while I was flying halfway across the\nworld) . I expect that it'll make it all the way to `master` without\nany issues.\n\nAlthough I've finished implementing an svndiff0 parser, I'm having\ntrouble integrating it into svn-fe; I'm currently attempting to\nrefactor the line_buffer library in svn-fe to load the diff into\nmemory all at once so that I can apply it. I've determined that unless\nsomeone else helps out, I might not be able to finish this within the\ntimeline of the SoC (related: my email earlier this week calling for\nmanpower) and get it merged.\n\nTo make svn-fe filesystem-aware, a LOT of refactoring is required. In\nshort, when a blob is required, it should issue an `M 040000 <SHA1>`\nto `git-fast-import` (see 334fba656b50 in `pu`) to fetch the right\ntree object when an SVN copyfrom is seen. To be able to do this\nhowever, it has to know the SHA1 of all the commits that it passes to\ngit-fast-import: this information must come from git-fast-import. It\nneeds another patch to print the SHA1 of the commit objects everytime\nit finishes writing a commit. Related to this, there's a discussion\nabout how loose objects in the Git store aren't inaccessible by\ncallers (and how cat-file can be used in fast-import?). Again, I will\npersonally not be able to handle this in the SoC term.\n\n-- Ram\n"}]}