{"thread":{"id":"23198","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","startedAt":"2010-03-27T05:40:57Z","lastAt":"2010-03-29T20:04:53Z","messageCount":6,"participants":["Steven Michalske","Ramkumar Ramachandra","Eric Raymond"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"137933","messageId":"3d4937ff1003262240t6159d9c5sc9253f555c3aed1@mail.gmail.com","threadId":"23198","inReplyTo":null,"subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Steven Michalske","fromEmail":"smichalske@gmail.com","sentAt":"2010-03-27T05:40:57Z","receivedAt":"2010-03-27T05:40:57Z","isPatch":false,"sender":{"key":"smichalske@gmail.com","avatar":"https://gravatar.com/avatar/721f27456adc9ac84f3bb235f021a70015abb9e09222ae8622fc5579c6a203c1?d=mp&s=160"},"body":"Ramkumar Ramachandra gmail.com> writes:\n---8<------\n> The following resources are relevant to the project:\n> 1. git_remote_helpers/git/git.py is a minimalistic remote helper\n> written by Sverre. I plan to extend this as much as possible before\n> rewriting it in C.\n\nWould cython meet the needs of increasing the speed of the python code\nwithout requiring a rewrite?\n\n> 2. libsvn contains excellent documentation and clear examples to\n> create the SVN client.\n> 3. git-svn.perl has a lot functionality that I plan to re-implement in\n> native-git-svn:\n> 3.1 parse_svn_date: Given a date (in UTC) from Subversion, return a\n> string in the format \" \" that Git will use\n> 3.2 load_authors: = real-name \n> mapping based on git-svnimport\n\nOne feature that I would like to see is a way to call an application for a name\nlookup author file maintenance.\n\ni.e. if the SVN authors file is missing the lookup, call the lookup tool.\n\nI work at a company with a LDAP server that I can look up the svn username to\nget real name and email address. This way I don't have to manually maintain a\nsvn authors file.\n\nThis is really a remote helper component, not just SVN\n\n> 3.3 do_git_init_db: Create and maintain svn-remotes\n> 3.4 get_commit_entry: Parse commit messages, and encode them; SVN\n> requires messages to be UTF-8 when entering the repo\n> 3.5 cmd_branch: Handle branching/ tagging\n\nI'm torn on how the current system handles this, I like all tags to\nbe tags, and\nthat if a tag had a branch like behavior (bad SVN users!), that a branch exists\nfor it, with the tag pointing to its branches head.\n\n> 3.6 cmd_create_ignore: Reads svn:ignore and puts the information\n> into .gitignore\n> 4. There are several existing third-party SVN exporters worth looking into [2].\n-----8<------\n\nA couple of side thoughts.\n\n--\nSupport for SVN's blank folders. Some of the old build systems I have used\nneed the blank folders, so I have to create to make the build work :-(\ncan't use\ngit-bisect easily. Well it's that i have to make the bisect run\nscript make the\nneeded folders, not too hard, but annoying. Could we track if in a particular\nSVN revision we had a blank folder that was either created or removed. Stuff a\nhidden file '.git_svn_empty_folder' or a .gitignore with a * in it so\ngit can then\ntrack the SVN's empty folder, and if the SVN folder gets contents the\n.git_ignore\nneeds the ignore removed?\n\n--\nOne of my SVN repositories using the current system fails to import that\nrepository is missing a revision in its SVN history. In other words\nthe SVN repo\nhas corrupted history the current git-svn will fail to import the repository.\n\nExample: R31 of the SVN repo is this status, R32 fails to checkout\ndue to a SVN\nerror, but R33 will checkout and is valid. I would like to see the\nhelper pause\nand ask me what to do. Either fail or skip that revision. It's a\nshame the history\nis gone, but I now have to tell the current git-svn to do a shallow clone and\nstart at R33 and I loose all of commits R1 to R31, This leads to branches that\nhave no known roots...... My case is this happened roughly at\nrevision 1700, the\nserver's hard drive crashed and restore was done with a backup that was at a\nrevision around 1500 so there is a big gap..... of lost history, but\nthat history is\n5-6 years old so the daily backups to reconstruct it are LONG gone.\nToo bad we didn't have git back then, could have restored all the\nhistory with a\npush! ;-)\n\nIf you want me to test your work on a hairy repository with corrupt history and\nthousands of branches, I'll do that for you.\n\n\n--\nIn that same corrupt repository, each branch has a large PDF that NEVER\nchanges. This makes me think that it might make exports faster if I could tell\nthe SVN client that a file is static, and to only track if it gets\nremoved or size\nchanges, don't know if libsvn would let you do that.... You might\neven be able\nto detect that kind of condition, large unchanging binary like files,\n might make a great bandwidth/speed optimization.\n\n\n\nSorry if I didn't see these points brought up in other emails on your\nproposal.\nBut working at a company with lots of history in SVN makes me passionate\nabout the SVN integration in git :-)\n\n\nGood luck!\nSteve\n"},{"id":"137934","messageId":"f3271551003262346g286e7e72u751e15cbc99a9c1@mail.gmail.com","threadId":"23198","inReplyTo":"3d4937ff1003262240t6159d9c5sc9253f555c3aed1@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-03-27T06:46:27Z","receivedAt":"2010-03-27T06:46:27Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"[Please don't cull people from cc]\n\n> Would cython meet the needs of increasing the speed of the python code\n> without requiring a rewrite?\n\nActually, I've subsequently decided that this is unnecessary. Besides,\nI'm writing in C mainly for portability to msysgit (Windows). Could\nyou please look at the updated version of my project proposal?\n\n> I work at a company with a LDAP server that I can look up the svn username to\n> get real name and email address.  This way I don't have to manually maintain a\n> svn authors file.\n\n> I'm torn on how the current system handles this,  I like all tags to\n> be tags, and\n> that if a tag had a branch like behavior (bad SVN users!), that a branch exists\n> for it, with the tag pointing to its branches head.\n\nThis shouldn't be a problem to implement/ improve at the end of my\nGSoC term. However, it's important that I don't lose focus and\nconcentrate on the core task at hand for GSoC, which is more about\ngetting native support for SVN than anything else. I have neither the\nexpertise or time (one GSoC term) to build a fantastic importer and\nget native support: I will be re-using several parts of existing\nimporters for the purpose of the GSoC.\n\n> Support for SVN's blank folders.  Some of the old build systems I have used\n> need the blank folders, so I have to create to make the build work :-(\n\nOkay, this should be simple enough to implement. Thank you for pointing it out.\n\n> One of my SVN repositories using the current system fails to import that\n> repository is missing a revision in its SVN history.  In other words\n> the SVN repo\n> has corrupted history the current git-svn will fail to import the repository.\n\nI'll keep this in mind when designing svn-fast-import: a certain\nrevision's checkout can fail, and a mechanism to bail the user out of\nsuch a situation can be helpful. Again, I can't promise that this'll\nbe completed by the end of the GSoC term, but I will make it easy\nenough to write the functionality in later on.\n\n> If you want me to test your work on a hairy repository with corrupt history and\n> thousands of branches, I'll do that for you.\n\nThanks! That'll be wonderful. If my proposal gets accepted, I\ncertainly will contact you (and several others) for testing, once the\ncore task of the GSoC is complete.\n\n> But working at a company with lots of history in SVN makes me passionate\n> about the SVN integration in git :-)\n\nGood to know. Thank you for your support :)\n\n-- Ram\n"},{"id":"137936","messageId":"9C72512D-F49A-4E94-A5D2-5F8D5BCCDFFA@gmail.com","threadId":"23198","inReplyTo":"f3271551003262346g286e7e72u751e15cbc99a9c1@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Steven Michalske","fromEmail":"smichalske@gmail.com","sentAt":"2010-03-27T08:03:13Z","receivedAt":"2010-03-27T08:03:13Z","isPatch":false,"sender":{"key":"smichalske@gmail.com","avatar":"https://gravatar.com/avatar/721f27456adc9ac84f3bb235f021a70015abb9e09222ae8622fc5579c6a203c1?d=mp&s=160"},"body":"On Mar 26, 2010, at 11:46 PM, Ramkumar Ramachandra \n wrote:\n\n> [Please don't cull people from cc]\n\nI didn't intend to, I wasn't on the mailing list before and the \nmessage was not a reply to but a new message with the same subject.\n>\n>> Would cython meet the needs of increasing the speed of the python \n>> code\n>> without requiring a rewrite?\n>\n> Actually, I've subsequently decided that this is unnecessary. Besides,\n> I'm writing in C mainly for portability to msysgit (Windows). Could\n> you please look at the updated version of my project proposal?\n>> I work at a company with a LDAP server that I can look up the svn \n>> username to\n>> get real name and email address. This way I don't have to manually \n>> maintain a\n>> svn authors file.\n>\n>> I'm torn on how the current system handles this, I like all tags to\n>> be tags, and\n>> that if a tag had a branch like behavior (bad SVN users!), that a \n>> branch exists\n>> for it, with the tag pointing to its branches head.\n>\n> This shouldn't be a problem to implement/ improve at the end of my\n> GSoC term. However, it's important that I don't lose focus and\n> concentrate on the core task at hand for GSoC, which is more about\n> getting native support for SVN than anything else. I have neither the\n> expertise or time (one GSoC term) to build a fantastic importer and\n> get native support: I will be re-using several parts of existing\n> importers for the purpose of the GSoC.\n>\nClean documented locations for adding the calling of these kinds of \naddons is all that's needed, then us other folks can chip in too with \nthe bits like the LDAP support.\n\n>> Support for SVN's blank folders. Some of the old build systems I \n>> have used\n>> need the blank folders, so I have to create to make the build \n>> work :-(\n>\n> Okay, this should be simple enough to implement. Thank you for \n> pointing it out.\n>\n>> One of my SVN repositories using the current system fails to import \n>> that\n>> repository is missing a revision in its SVN history. In other words\n>> the SVN repo\n>> has corrupted history the current git-svn will fail to import the \n>> repository.\n>\n> I'll keep this in mind when designing svn-fast-import: a certain\n> revision's checkout can fail, and a mechanism to bail the user out of\n> such a situation can be helpful. Again, I can't promise that this'll\n> be completed by the end of the GSoC term, but I will make it easy\n> enough to write the functionality in later on.\n>\n>> If you want me to test your work on a hairy repository with corrupt \n>> history and\n>> thousands of branches, I'll do that for you.\n>\n> Thanks! That'll be wonderful. If my proposal gets accepted, I\n> certainly will contact you (and several others) for testing, once the\n> core task of the GSoC is complete.\n>\n>> But working at a company with lots of history in SVN makes me \n>> passionate\n>> about the SVN integration in git :-)\n>\n> Good to know. Thank you for your support :)\n>\n> -- Ram\n\nHappy hacking!\n"},{"id":"137939","messageId":"20100327091938.GA4395@thyrsus.com","threadId":"23198","inReplyTo":"3d4937ff1003262240t6159d9c5sc9253f555c3aed1@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Eric Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2010-03-27T09:19:38Z","receivedAt":"2010-03-27T09:19:38Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Steven Michalske :\n> > 3.5 cmd_branch: Handle branching/ tagging\n> \n> I'm torn on how the current system handles this, I like all tags to\n> be tags, and\n> that if a tag had a branch like behavior (bad SVN users!), that a branch exists\n> for it, with the tag pointing to its branches head.\n\nAh. This sounds like s discussion, pre-dating my joining the list, of\nmy issue #2 about git-svn - not rendering unmodified tag directories as\ngit tags. It's good that someone wants to rackle this seriously.\n-- \n\t\tEric S. Raymond\n"},{"id":"138002","messageId":"20100328121034.GC25402@thyrsus.com","threadId":"23198","inReplyTo":"f3271551003280225v17af30d4s6d3d24b4d548ff7d@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Eric Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2010-03-28T12:10:34Z","receivedAt":"2010-03-28T12:10:34Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Ramkumar Ramachandra :\n> Project Proposal: git-remote-svn | Native SVN support in Git\n> Student: Ramkumar Ramachandra\n> Mentor: Sverre Rabbelier\n\n+1\n\nI've just been through a Subversion-to-git migration, and have been\ndirectly affected by an inadequacy in git-svn - failure to recognizer\nSVN tags as tags rather than branches. See my blog post at\n, \"Subversion to GIT Migration: A Tale\nof Two Gotchas\" for discussion.\n\nAccordingly, I support Ramkumar's proposal to rethink and rewrite the \nSubversion interface. A concerted effort to do seamless interoperability \nwould be well justified given the ubiquity of Subversion. I think Rankumar\nhas chosen a goal that is useful, well defined, and realistically scoped.\n-- \n\t\tEric S. Raymond\n"},{"id":"138126","messageId":"f3271551003291304u27c56d8fr648d7546f6256857@mail.gmail.com","threadId":"23198","inReplyTo":"20100328121034.GC25402@thyrsus.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-03-29T20:04:53Z","receivedAt":"2010-03-29T20:04:53Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nJust a quick heads up: I've submitted my proposal via Google.\n\nOn Sun, Mar 28, 2010 at 5:40 PM, Eric Raymond wrote:\n> Accordingly, I support Ramkumar's proposal to rethink and rewrite the\n> Subversion interface.  A concerted effort to do seamless interoperability\n> would be well justified given the ubiquity of Subversion.  I think Rankumar\n> has chosen a goal that is useful, well defined, and realistically scoped.\n\nThank you :) I'll do my best.\n\n-- Ram\n"}]}