{"thread":{"id":"23083","subject":"native-git-svn: A Summer of Code 2010 proposal","startedAt":"2010-03-19T17:18:27Z","lastAt":"2010-03-23T07:49:39Z","messageCount":33,"participants":["Ramkumar Ramachandra","Avery Pennarun","Sverre Rabbelier","Jonathan Nieder","Johannes Schindelin","Daniel Barkalow","Peter Baumann","Jakub Narebski","Ilari Liusvaara","Dave Olszewski","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"137245","messageId":"f3271551003191018j67aa133es2fee4e3dda519ce0@mail.gmail.com","threadId":"23083","inReplyTo":null,"subject":"native-git-svn: A Summer of Code 2010 proposal","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-03-19T17:18:27Z","receivedAt":"2010-03-19T17:18:27Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nI picked up a project I liked from the Wiki\n[https://git.wiki.kernel.org/index.php/SoC2010Ideas#A_remote_helper_for_svn]\nand discussed it with Sverre. I now have a preliminary draft of my\nproposal ready, and I'd really appreciate feedback.\n\n=====================================\nProject Proposal: native-git-svn | Native SVN support in Git\n\n== The Outline ==\nCurrently, git-svn.perl is used to interface with SVN repositories.\nHowever, it has serious shortcomings:\n1. It is essentially an arcane 5000-line Perl script that doesn't use\ngit-fast-import/ git-fast-export. It converts an SVN repository to a\nGit repository by hand. This makes it virtually unmaintainable.\n2. Its UI is unnecessarily complex. git-svn-* has some commands\ncorresponding to git-* commands, and it can be quite difficult for the\nuser to understand which one to use in different situations. These can\nbe merged easily.\n3. It handles the standard trunk/branches/tags layout well, but it\ndoesn't know how to handle non-standard/ changing SVN layout.\n4. There's an array of other annoyances which makes it quite\nimperfect. For example, it ignores all SVN properties except\nsvn:executable.\n\nWhile many of these problems can be tackled in git-svn.perl itself,\nproblem 1 is the most prominent. git-svn.perl is very difficult to\nmodify or even maintain. A more permanent solution is required.\n\nMy proposal is to start from scratch and build an application that\nmakes dealing SVN repositories very easy. The plan is to build\ncomponent-wise, in a modular manner. The project can be considered\nfully successful only after the functionality described in all the\ncomponents have been written, and the project is merged into upstream.\nIt will involve minimal changes to the current Git codebase, if any at\nall. I additionally hope that this project will serve as a roadmap for\nother projects that involve natively supporting other versioning\nsystems in Git.\n\n== The Technicalities ==\nThe distinct components I plan to write are:\n1. An SVN client that uses libsvn to fetch/ push revisions to a remote\nSVN repository.\n2. An exporter for SVN repositories, which will extract all the\nrelevant revision history and metadata to import into Git.\n3. A remote helper for Git that takes the data from this SVN exporter,\nand uses git-fast-import to create corresponding commits in Git.\n4. Another remote helper to export commit data and metadata from Git\nto import into SVN.\n5. An importer for SVN, which will create revisions in SVN\ncorresponding to commits in Git.\n6. A UI that glues all the components together into one large\nconsistent interface.\n\nDue to a licensing conflict, the details of which can be found here\n[1], native-git-svn will link to libsvn, but will NOT link to Git. It\nwill simply use a thin wrapper to call compiled Git executables\n(referred to as remote helper in article). The six components will be\ndeveloped and tested independently.\n\nThe following resources are relevant to the project:\n1. git_remote_helpers/git/git.py is a minimalistic remote helper\nwritten by Sverre. I plan to extend this as much as possible before\nrewriting it in C.\n2. libsvn contains excellent documentation and clear examples to\ncreate the SVN client.\n3. git-svn.perl has a lot functionality that I plan to re-implement in\nnative-git-svn:\n 3.1 parse_svn_date: Given a date (in UTC) from Subversion, return a\nstring in the format \" \" that Git will use\n 3.2 load_authors: = real-name \nmapping based on git-svnimport\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\nrequires messages to be UTF-8 when entering the repo\n 3.5 cmd_branch: Handle branching/ tagging\n 3.6 cmd_create_ignore: Reads svn:ignore and puts the information\ninto .gitignore\n4. There are several existing third-party SVN exporters worth looking into [2].\n\nI've additionally discussed the project with Sverre Rabbelier at\nlength over email.\n\n== Who am I? ==\nI'm Ramkumar, a student at the Indian Institute of Technology,\nKharagpur. I haven't contributed more than a few small patches to Git\n[3], and I look at this project as a fantastic opportunity to get more\ninvolved with the community. In the summer and winter of 2008, I\nworked with a Django-based startup. The team comprised of three\nexperienced Python developers, one designer to steer the project, and\nan undergraduate student- me. We versioned everything on Git, deployed\non Apache/ PostgreSQL, using Amazon S3 for static content. While\nworking with the startup, I also contributed to South, a migration\nframework for Django. A lot more about this is mentioned on my resume\n[4].\n\nC, C++ [5], and Python are my strongest languages. I've additionally\nlearnt Common Lisp through an Emacs Lisp application I wrote in summer\n2009 [6]. I'm known to be very communicative, both in person, and over\nemail/ chat. The style and clarity of my communication is seen in the\nslides I used at FOSS.IN/2009 in winter 2009 [7].\n\n== Notes ==\n[1] http://thread.gmane.org/gmane.comp.version-control.git/139545\n[2] svn-all-fast-export | git://repo.or.cz/svn-all-fast-export.git and\nfast-export | git://repo.or.cz/fast-export.git\n[3] 52eb5173ac and 88d50e78c3\n[4] TODO\n[5] On a related note, I've also contributed a little to Chromium\n[6] http://github.com/artagnon/ublog.el\n[7] http://artagnon.com/wp-content/uploads/haskell-internals.pdf and\nhttp://artagnon.com/wp-content/uploads/unladen-swallow.pdf\n=====================================\n\nThanks!\n\nRegards,\nRamkumar\n"},{"id":"137250","messageId":"32541b131003191132y119037f8rae598d0037786703@mail.gmail.com","threadId":"23083","inReplyTo":"f3271551003191018j67aa133es2fee4e3dda519ce0@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-03-19T18:32:59Z","receivedAt":"2010-03-19T18:32:59Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, Mar 19, 2010 at 1:18 PM, Ramkumar Ramachandra\n wrote:\n> 1. It is essentially an arcane 5000-line Perl script that doesn't use\n> git-fast-import/ git-fast-export. It converts an SVN repository to a\n> Git repository by hand. This makes it virtually unmaintainable.\n> [...]\n> My proposal is to start from scratch and build an application that\n> makes dealing SVN repositories very easy. The plan is to build\n> component-wise, in a modular manner. The project can be considered\n> fully successful only after the functionality described in all the\n> components have been written, and the project is merged into upstream.\n\n\"I don't understand the current implementation\" is approximately the\nworst possible reason to rewrite something from scratch. Here is a\ngreat article about this problem:\nhttp://www.joelonsoftware.com/articles/fog0000000069.html (from back\nbefore Joel \"junked the sharp\").\n\nNow, git-svn is not as big a project as, say, Netscape or dBase or\nQuattro Pro. It's just a little piece. So rewriting from scratch\n*might* actually work in this case. But you should be aware that:\n\n- a lot of the complexity is there for a reason\n\n- all those \"extra commands\" that git-svn supports are considered\nbackwards compatibility, even if they're absolutely obsolete because\nof newer commands, and therefore will be very hard to justify getting\nrid of\n\n- getting your replacement merged into git is rather unlikely unless\nyou can provide this backwards compatibility *and* a comparable\nfeature set, or at least a compelling reason that yours should be\nmerged in *alongside* the existing git-svn, resulting in duplicate\nfunctionality.\n\nSo if your goal is to write a possibly better replacement to git-svn,\nthat's a potentially great goal with an unfortunately high probability\nof failure (but great upside if you don't fail). If you won't\nconsider it successful unless it gets merged upstream... then you're\nsetting yourself up for disappointment, at least if you expect to be\ndone withing the GSoC timeframe.\n\nSo that's the \"downer\" part of my feedback. On the other hand, I\ndon't really like how git-svn works either, so I'd be happy to also\noffer some constructive suggestions if you really are brave enough to\nstart from scratch :)\n\n> 3. It handles the standard trunk/branches/tags layout well, but it\n> doesn't know how to handle non-standard/ changing SVN layout.\n\nIndeed. After fiddling with git-svn more than I'd like to think about\n(we use a mishmash of git and svn at work, both with lots of branches,\nand I'm basically the junction point between them), I have come to a\nsimple conclusion:\n\n ** Trying to map the svn branch-is-a-folder model to git's\nbranch-is-a-branch model is wrong. **\n\ngit-svn tries to take /trunk/* and /branches/foo/* and pretend that\nthe '*' in each corresponds to the same set of files, separated only\nby history. This is more-or-less true in most svn repositories...\nsome more and some less. But the mapping is never 100% correct, and\nonce you've done the mapping, it's impossible to fix without doing a\nwhole new import. Moreover, extracting these branches separately from\nthe svn history often involves downloading the same file contents over\nand over, which is stupid and slow. git-svn goes through many\ncontortions to *avoid* such re-downloading, but it isn't always\nsuccessful; sooner or later it ends up re-downloading a tonne of\nstuff. And this is despite the fact that svn has *explicit* recording\nof renames and copies, which ought to be easy for git-svn to read and\nsay \"just copy the treeid corresponding to the source and paste it\ninto the destination\" as a trivial O(1) operation.\n\nSo anyway, my suggestion here is to do something so simple it's not\nobvious: import the entire history, one revision at a time, from the\nvery top of the svn tree. That means the git history will show\n/branches/whatever/* *and* /trunk/*, and 99% of the files will be the\nsame. Of course, the fact that they're the same costs you nothing,\nbecause git is awesome. You only pay for it if you check out that\nmagic history branch into your working tree.\n\nAnd that's the trick: you never want to actually check out this\nfull-history branch. Instead, use something like the technique from\n'git subtree split' (http://github.com/apenwarr/git-subtree) to\nextract sub-histories *from that primary imported history*. That\nsplit operation can happen *really* fast, since all you're doing is\ncreating a bunch of synthetic git commits where the toplevel tree\npoints at the subtree from the corresponding commit in the primary\nhistory. Creating a bunch of tiny commit objects is quick and easy.\nAnd if you screw it up, no problem; just throw it away and regenerate\nthe subtree. None of that requires re-importing stuff from the svn\nserver, which is the unbelievably slow and expensive part.\n\nSeparating these two concepts, svn importing from\nsvn-branch-directory-swizzling, ought to make git-svn much more\nmanageable, much faster, and much more flexible.\n\n> 4. There's an array of other annoyances which makes it quite\n> imperfect. For example, it ignores all SVN properties except\n> svn:executable.\n\nYes, you'll have to find a good solution to this that balances one set\nof disadvantages (file attributes that aren't stored, or are stored\ninvisibly) with another (file attributes that are stored in dotfiles\nor something and thus clutter up the work tree).\n\nMaybe git-notes would help. Or maybe not :)\n\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\nAre you sure you really want to rewrite git-svn in C? svn is so slow\nthat interpreted vs. native performance is unlikely to be an issue.\ngit-svn is probably not going to be needed on embedded systems where\ninstalling python or perl is a problem. And managing the data\nstructures in a high-level language should be a lot easier.\n\nYou could always do your whole project in python or perl and make it\n*work* the way you want. If it's really good, you can maybe get that\naccepted into the git core. Then, if it's really modular enough, you\nought to be able to rewrite the modules one by one into C as needed.\n\nHave fun,\n\nAvery\n"},{"id":"137251","messageId":"fabb9a1e1003191139v6ea37df3uba441f2cba9bc992@mail.gmail.com","threadId":"23083","inReplyTo":"32541b131003191132y119037f8rae598d0037786703@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-03-19T18:39:55Z","receivedAt":"2010-03-19T18:39:55Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Fri, Mar 19, 2010 at 19:32, Avery Pennarun wrote:\n> - all those \"extra commands\" that git-svn supports are considered\n> backwards compatibility, even if they're absolutely obsolete because\n> of newer commands, and therefore will be very hard to justify getting\n> rid of\n\nI don't think this is true. The proposal is to implement\ngit-remote-svn, which would allow _native_ interaction with svn\nrepositories, so without using 'git svn'. It would allow 'git clone\nsvn://example.com/myrepo' and subsequent \"git pull\"s from that svn\nsource. Do you agree that makes (part of) your comments moot, or am I\nmissing something?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"137267","messageId":"20100319205301.GA15053@progeny.tock","threadId":"23083","inReplyTo":"32541b131003191132y119037f8rae598d0037786703@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-03-19T20:53:01Z","receivedAt":"2010-03-19T20:53:01Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Avery Pennarun wrote:\n> On Fri, Mar 19, 2010 at 1:18 PM, Ramkumar Ramachandra\n\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>\n> Are you sure you really want to rewrite git-svn in C? svn is so slow\n> that interpreted vs. native performance is unlikely to be an issue.\n> git-svn is probably not going to be needed on embedded systems where\n> installing python or perl is a problem. And managing the data\n> structures in a high-level language should be a lot easier.\n\nHmm. Sverre discussed why this is more about a redesign of svn\ninterop support than a C reimplementation of git-svn. I wouldn’t mind\nif at the end of the summer, all we have is some working Python code.\nStill, it would have to be rewritten in C or Perl before msysgit could\nuse it unless some hero packages a Python interpreter for them.\n\nJonathan\n"},{"id":"137269","messageId":"alpine.DEB.1.00.1003192159300.7596@pacific.mpi-cbg.de","threadId":"23083","inReplyTo":"20100319205301.GA15053@progeny.tock","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-03-19T21:00:34Z","receivedAt":"2010-03-19T21:00:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 19 Mar 2010, Jonathan Nieder wrote:\n\n> Avery Pennarun wrote:\n> > On Fri, Mar 19, 2010 at 1:18 PM, Ramkumar Ramachandra\n> \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> >\n> > Are you sure you really want to rewrite git-svn in C? svn is so slow\n> > that interpreted vs. native performance is unlikely to be an issue.\n> > git-svn is probably not going to be needed on embedded systems where\n> > installing python or perl is a problem. And managing the data\n> > structures in a high-level language should be a lot easier.\n> \n> Hmm. Sverre discussed why this is more about a redesign of svn\n> interop support than a C reimplementation of git-svn. I wouldn’t mind\n> if at the end of the summer, all we have is some working Python code.\n> Still, it would have to be rewritten in C or Perl before msysgit could\n> use it unless some hero packages a Python interpreter for them.\n\nIt's not about packaging the interpreter. It is about _compiling_ it, so \nthat we can also compile native extensions for performance.\n\nLast time I tried to compile Python with MSys, I gave up. After a full \nweek of trying.\n\nCiao,\nDscho\n"},{"id":"137272","messageId":"32541b131003191430ld0eaa9cw1d2aac08cff15682@mail.gmail.com","threadId":"23083","inReplyTo":"fabb9a1e1003191139v6ea37df3uba441f2cba9bc992@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-03-19T21:30:09Z","receivedAt":"2010-03-19T21:30:09Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, Mar 19, 2010 at 2:39 PM, Sverre Rabbelier wrote:\n> On Fri, Mar 19, 2010 at 19:32, Avery Pennarun wrote:\n>> - all those \"extra commands\" that git-svn supports are considered\n>> backwards compatibility, even if they're absolutely obsolete because\n>> of newer commands, and therefore will be very hard to justify getting\n>> rid of\n>\n> I don't think this is true. The proposal is to implement\n> git-remote-svn, which would allow _native_ interaction with svn\n> repositories, so without using 'git svn'. It would allow 'git clone\n> svn://example.com/myrepo' and subsequent \"git pull\"s from that svn\n> source. Do you agree that makes (part of) your comments moot, or am I\n> missing something?\n\nI don't know enough about the proposal to comment on this part of the design.\n\nI do know that where git-svn fits into git's UI has not been the\nproblem for me or my co-workers; we can learn some weirdo syntax if\nneeded. Things like branching and merging, and git-svn redownloading\nthe same stuff 100 times, and oddly-named-svn-branch-hierarchies, and\ngit pulling between git-svn users, however, have given us lots of\ngrief.\n\nFor example, I'd be very happy to learn that your new design would\nallow two people to independently pull from svn://, do work in their\nrespective copies of the git repositories, branch and merge all day\nlong, pull from each other, and then push back to svn without a)\nmaking a mess of the svn repo and causing zillions of conflicts, or b)\nlinearizing history and losing git's complex DAG.\n\nIn the current version of git-svn this is very hard. 'git svn dcommit'\ngenerates entirely new git commit objects corresponding to the ones\nthat were created in svn... but which nevertheless have your merge\nhistory included, which is awesome. But if a new person clones the\nsvn repo from scratch, he will end up with git commits corresponding\nto those same ones from svn, but *without* the merge history, and\ntherefore with different commit ids, and which therefore prevent\npush/pulling between other people who have cloned the repo.\n\nIf the above explanation doesn't make any sense, let me know and I can\nclarify it further. If you know what I'm talking about and have\neither solved it or don't care about that use case, please just ignore\nme and I'll go back to hide in my hole :)\n\nHave fun,\n\nAvery\n"},{"id":"137321","messageId":"f3271551003200219s5da3d620n602227eed948da70@mail.gmail.com","threadId":"23083","inReplyTo":"32541b131003191430ld0eaa9cw1d2aac08cff15682@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-03-20T09:19:43Z","receivedAt":"2010-03-20T09:19:43Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\n> So if your goal is to write a possibly better replacement to git-svn,\n> that's a potentially great goal with an unfortunately high probability\n> of failure (but great upside if you don't fail). If you won't\n> consider it successful unless it gets merged upstream... then you're\n> setting yourself up for disappointment, at least if you expect to be\n> done withing the GSoC timeframe.\n\nAs Sverre pointed out, this is not the goal of the project. The\nproposal is not to rewrite git-svn. You're probably right to assume\nthat any such endeavor would be unsuccessful in one summer. The\nproposal is to create an application that will natively support SVN\nrepositories in Git. I'm simply pointing out the limitations of\ngit-svn as a motivation for this project.\n\nAs I've mentioned in my proposal, good SVN exporters already exist,\nand creating an SVN client can be fairly elementary. The whole point\nof the project is to move away from the \"git-svn.perl approach\".\nOfcourse, that doesn't mean that I won't use some parts of git-svn in\nnative-git-svn. Along with creating the infrastructure for this\napproach, I do expect to have *working* native SVN support at the end\nof summer merged into mainline.\n\nI'll make this clearer in the next revision of my proposal.\n\n> You could always do your whole project in python or perl and make it\n> *work* the way you want. If it's really good, you can maybe get that\n> accepted into the git core. Then, if it's really modular enough, you\n> ought to be able to rewrite the modules one by one into C as needed.\n\nWriting everything in C can be quite painful. I plan to start off by\nprototyping the various components in Python anyway. If and when it's\nnecessary, components can be re-implemented in C.\n\n> In the current version of git-svn this is very hard. 'git svn dcommit'\n> generates entirely new git commit objects corresponding to the ones\n> that were created in svn... but which nevertheless have your merge\n> history included, which is awesome.  But if a new person clones the\n> svn repo from scratch, he will end up with git commits corresponding\n> to those same ones from svn, but *without* the merge history, and\n> therefore with different commit ids, and which therefore prevent\n> push/pulling between other people who have cloned the repo.\n\nOh, that's terribly ugly. Thanks for pointing it out. I haven't\nthought of a solution yet, but yes- it would be really nice if the new\ndesign could handle this elegantly.\n\nDo feel free to tell me what you'd like to see in the next revision of\nmy proposal, and what you'd like to see omitted. A proposal can't run\ninto many pages, so I'll attach anything that's very detailed as\nnotes.\n\nThanks,\nRamkumar\n"},{"id":"137323","messageId":"alpine.DEB.1.00.1003201148230.7596@pacific.mpi-cbg.de","threadId":"23083","inReplyTo":"32541b131003191430ld0eaa9cw1d2aac08cff15682@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-03-20T10:48:42Z","receivedAt":"2010-03-20T10:48:42Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 19 Mar 2010, Avery Pennarun wrote:\n\n> On Fri, Mar 19, 2010 at 2:39 PM, Sverre Rabbelier wrote:\n> > On Fri, Mar 19, 2010 at 19:32, Avery Pennarun wrote:\n> >> - all those \"extra commands\" that git-svn supports are considered\n> >> backwards compatibility, even if they're absolutely obsolete because\n> >> of newer commands, and therefore will be very hard to justify getting\n> >> rid of\n> >\n> > I don't think this is true. The proposal is to implement\n> > git-remote-svn, which would allow _native_ interaction with svn\n> > repositories, so without using 'git svn'. It would allow 'git clone\n> > svn://example.com/myrepo' and subsequent \"git pull\"s from that svn\n> > source. Do you agree that makes (part of) your comments moot, or am I\n> > missing something?\n> \n> I don't know enough about the proposal to comment on this part of the \n> design.\n\nHow about reading it? It's on the Wiki.\n\nCiao,\nDscho\n"},{"id":"137367","messageId":"f3271551003201334o4919cd47s44d06288b0d6068b@mail.gmail.com","threadId":"23083","inReplyTo":"alpine.DEB.1.00.1003201148230.7596@pacific.mpi-cbg.de","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-03-20T20:34:40Z","receivedAt":"2010-03-20T20:34:40Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nI just prepared another revision of my proposal- I've tried to be\nclearer about the objective, and included a timeline this time. Note\nthat I've also changed the name from native-git-svn to git-remote-svn,\nas recommended by Sverre.\n\n======================================\nProject Proposal: git-remote-svn | Native SVN support in Git\n\n== The Outline ==\nThe objective of git-remote-svn is to allow native interaction with\nSVN repositories in Git. The motivation for writing this comes from\nthe shortcomings of the current approach: git-svn.\n1. It is essentially an arcane 5000-line Perl script that doesn't use\ngit-fast-import/ git-fast-export. It converts an SVN repository to a\nGit repository by hand. This makes it virtually unmaintainable.\n2. The UI is unnatural and complex. git-svn-* has some commands\ncorresponding to git-* commands, and it can be quite difficult for the\nuser to understand which one to use in different situations.\n3. It handles the standard trunk/branches/tags layout well, but it\ndoesn't know how to handle non-standard/ changing SVN layout.\n4. There's an array of other annoyances which makes it quite\nimperfect. For example, it ignores all SVN properties except\nsvn:executable.\n\nWhile the last two problems can be tackled in git-svn.perl itself, a\nfresh approach is required to tackle the first two. git-remote-svn is\na proposal for an alternative approach.\n1. Several good SVN exporters already exist, and using them with\ngit-fast-import should simplify a lot of the plumbing git-svn tackles\nby hand.\n2. Using a remote helper to keep track of SVN remotes will simplify\nthe UI greatly. The fresh UI will allow for a simple `git clone\nsvn://example.com/myrepo` and multiple subsequent `git pull`\ninvocations.\n\nHowever, the project does not aim to be compatible with git-svn, and\ndoes not serve as an immediate replacement. It can be considered fully\nsuccessful after the functionality described in all the components\nhave been written. Merging the project to upstream will involve small\nchanges to the Git codebase to incorporate the native UI. I\nadditionally hope that this project will serve as a roadmap for other\nprojects that involve natively supporting other versioning systems in\nGit.\n\n== The Technicalities ==\nI've discussed the project with Sverre Rabbelier at length over email.\nThe plan is to build component-wise. The distinct components are:\n1. An SVN client that uses libsvn to fetch/ push revisions to a remote\nSVN repository.\n2. An exporter for SVN repositories, which will extract all the\nrelevant revision history and metadata to import into Git.\n3. A remote helper for Git that takes the data from this SVN exporter,\nand uses git-fast-import to create corresponding commits in Git.\n4. Another remote helper to export commit data and metadata from Git\nto import into SVN.\n5. An importer for SVN, which will create revisions in SVN\ncorresponding to commits in Git.\n6. A UI that glues all the components together.\n\nDue to a licensing conflict, the details of which can be found here\n[1], git-remote-svn will link to libsvn, but will NOT link to Git. It\nwill simply use a thin wrapper to call compiled Git executables\n(referred to as remote helper in article). The following resources\nwill help build the various components:\n1. git_remote_helpers/git/git.py is a small remote helper written by\nSverre that wraps around git-fast-import. I plan to extend this to\nwrap around git-fast-export as well.\n2. git-svn.perl contains a two-way mapping, parts of which I plan to implement.\n3. Thiago Macieira's svn-all-fast-export [2] has a complete SVN -> Git\nmapping. I plan to take several ideas from the branch/ tag mapper in\nrepository.cpp.\n\n== Timeline ==\nApril 26 - May 24: Study svn-all-fast-export extensively, and chalk\nout a mapper for SVN branches and tags. Take time to become\ncomfortable with libsvn.\nMay 24 - June 10: Write a minimal importer/ exporter for SVN in\nPython. It should allow interconversion between commit messages,\ntimestamps, authors corresponding to each revision/ commit. Also\nfigure out how to preserve the data in SVN properties.\nJune 10 - June 25: Extend the the remote helper in\ngit_remote_helpers/git/git.py to do git-fast-export as well. Make the\nimporter/ exporter for SVN work with it.\nJune 25 - July 5: Implement a minimal SVN client, and make it work\nwith the SVN exporter.\nJuly 5 - July 10: Write a quick UI binder. This will involve\nmodifications to builtin-push, builtin-fetch, builtin-clone, and\nremote to use the SVN client to perform the corresponding actions in\nthe case of an SVN remote.\nJuly 10 - July 16: Scrub code and write documentation for mid-term\nevaluations. Commit changes to the remote helper to upstream. Try to\nget the other changes into `next`.\nJuly 17 - August 9: Implement the branch and tag mapper.\nAugust 9 - August 16: Write more documentation and get everything\nready for final evaluations. Commit the SVN importer/ exporter and UI\nchanges.\n\n== Who am I? ==\nI'm Ramkumar, a student at the Indian Institute of Technology,\nKharagpur. I haven't contributed more than a few small patches to Git\n[3], and I look at this project as a fantastic opportunity to get more\ninvolved with the community. In the summer and winter of 2008, I\nworked with a Django-based startup. The team comprised of three\nexperienced Python developers, one designer to steer the project, and\nan undergraduate student- me. We versioned everything on Git, deployed\non Apache/ PostgreSQL, using Amazon S3 for static content. While\nworking for the startup, I also contributed to South.\n\nC, C++ [4], and Python are my strongest languages. I've additionally\nlearnt Common Lisp through an Emacs Lisp I wrote in summer 2009 [5].\nI'm known to be very communicative, both in person, and over email/\nchat. The style and clarity of my communication is seen in the slides\nI used at FOSS.IN/2009 in winter 2009 [6].\n\n== Notes ==\n[1] http://thread.gmane.org/gmane.comp.version-control.git/139545\n[2] git://repo.or.cz/svn-all-fast-export.git\n[3] 52eb5173ac and 88d50e78c3\n[4] On a related note, I've also contributed a little to Chromium\n[5] http://github.com/artagnon/ublog.el\n[6] http://artagnon.com/wp-content/uploads/haskell-internals.pdf and\nhttp://artagnon.com/wp-content/uploads/unladen-swallow.pdf\n======================================\n\nAgain, I'd really appreciate comments.\n\nThanks,\nRamkumar\n"},{"id":"137371","messageId":"f3271551003201355h73deb7d8l8084335b09c01560@mail.gmail.com","threadId":"23083","inReplyTo":"f3271551003201334o4919cd47s44d06288b0d6068b@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-03-20T20:55:22Z","receivedAt":"2010-03-20T20:55:22Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"> July 5 - July 10: Write a quick UI binder. This will involve\n> modifications to builtin-push, builtin-fetch, builtin-clone, and\n> remote to use the SVN client to perform the corresponding actions in\n> the case of an SVN remote.\n\nCorrection: This functionality is already present. I'll just continue\nworking on my SVN client for this period.\n\nRegards,\nRamkumar\n"},{"id":"137375","messageId":"20100320210406.GA29899@progeny.tock","threadId":"23083","inReplyTo":"f3271551003201334o4919cd47s44d06288b0d6068b@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-03-20T21:04:07Z","receivedAt":"2010-03-20T21:04:07Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nRamkumar Ramachandra wrote:\n\n> I just prepared another revision of my proposal- I've tried to be\n> clearer about the objective, and included a timeline this time.\n\nVery nice. Thanks!\n\n> == Timeline ==\n\nThe one thing I worry about is that you are proposing to wait a while\nbefore submitting your changes upstream. I would suggest pushing\nwhatever pieces work to contrib/ early on to get more feedback from\nreviewers and testers. (I am saying this selfishly, as a potential\ntester.)\n\n> July 10 - July 16: Scrub code and write documentation for mid-term\n> evaluations. Commit changes to the remote helper to upstream. Try to\n> get the other changes into `next`.\n\nIn particular, this seems like very little time to get the code into\nshape for git.git.\n\nHope that helps.\n\nCheers,\nJonathan\n"},{"id":"137380","messageId":"alpine.LNX.2.00.1003201724270.14365@iabervon.org","threadId":"23083","inReplyTo":"f3271551003201334o4919cd47s44d06288b0d6068b@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2010-03-20T21:58:34Z","receivedAt":"2010-03-20T21:58:34Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 21 Mar 2010, Ramkumar Ramachandra wrote:\n\n> Hi,\n> \n> I just prepared another revision of my proposal- I've tried to be\n> clearer about the objective, and included a timeline this time. Note\n> that I've also changed the name from native-git-svn to git-remote-svn,\n> as recommended by Sverre.\n> \n> ======================================\n> Project Proposal: git-remote-svn | Native SVN support in Git\n> \n> == The Outline ==\n> The objective of git-remote-svn is to allow native interaction with\n> SVN repositories in Git. The motivation for writing this comes from\n> the shortcomings of the current approach: git-svn.\n> 1. It is essentially an arcane 5000-line Perl script that doesn't use\n> git-fast-import/ git-fast-export. It converts an SVN repository to a\n> Git repository by hand. This makes it virtually unmaintainable.\n> 2. The UI is unnatural and complex. git-svn-* has some commands\n> corresponding to git-* commands, and it can be quite difficult for the\n> user to understand which one to use in different situations.\n> 3. It handles the standard trunk/branches/tags layout well, but it\n> doesn't know how to handle non-standard/ changing SVN layout.\n> 4. There's an array of other annoyances which makes it quite\n> imperfect. For example, it ignores all SVN properties except\n> svn:executable.\n> \n> While the last two problems can be tackled in git-svn.perl itself, a\n> fresh approach is required to tackle the first two. git-remote-svn is\n> a proposal for an alternative approach.\n> 1. Several good SVN exporters already exist, and using them with\n> git-fast-import should simplify a lot of the plumbing git-svn tackles\n> by hand.\n> 2. Using a remote helper to keep track of SVN remotes will simplify\n> the UI greatly. The fresh UI will allow for a simple `git clone\n> svn://example.com/myrepo` and multiple subsequent `git pull`\n> invocations.\n> \n> However, the project does not aim to be compatible with git-svn, and\n> does not serve as an immediate replacement. It can be considered fully\n> successful after the functionality described in all the components\n> have been written. Merging the project to upstream will involve small\n> changes to the Git codebase to incorporate the native UI. I\n> additionally hope that this project will serve as a roadmap for other\n> projects that involve natively supporting other versioning systems in\n> Git.\n> \n> == The Technicalities ==\n> I've discussed the project with Sverre Rabbelier at length over email.\n> The plan is to build component-wise. The distinct components are:\n> 1. An SVN client that uses libsvn to fetch/ push revisions to a remote\n> SVN repository.\n> 2. An exporter for SVN repositories, which will extract all the\n> relevant revision history and metadata to import into Git.\n> 3. A remote helper for Git that takes the data from this SVN exporter,\n> and uses git-fast-import to create corresponding commits in Git.\n> 4. Another remote helper to export commit data and metadata from Git\n> to import into SVN.\n> 5. An importer for SVN, which will create revisions in SVN\n> corresponding to commits in Git.\n\nThe structure for remote helpers should be that each foreign system has a \nsingle helper which git can call with instructions on what to do (both for \nforeign-to-git and for git-to-foreign operations). So 3 and 4 have to be \nfunctions of the same program, and it's probably best for 2 and 5 and \nmaybe 1 to also be part of this program.\n\nThe structure is that git will essentially call you in a pipeline like:\n\n commands | you | git-fast-import\n\nor:\n\n git-fast-export | you | git-fast-import\n\nSo the helper wouldn't be running git-fast-export or git-fast-import, \nunless it was a helper for using git as the foreign system.\n\n> 6. A UI that glues all the components together.\n\nIf you use the remote-helper framework (and probably extend it as \nnecessary), there shouldn't need to be a UI. The grand idea is that, \nregardless of what mechanism you use to interact with git, it would use \nthe transport code from the library, which would know how to interact with \nremote helpers, and users and UI developers don't need to know about SVN \nor Perforce or any other particular system.\n\nAn extra-grand idea would be to allow helpers to be agnostic about the \nlocal system they're helping, so that Mercurial could use an SVN helper \nyou developed for git, and git could use a Darcs helper that the Darcs \npeople developed without a particular local system in mind, just to be \ninteroperable.\n\n> Due to a licensing conflict, the details of which can be found here\n> [1], git-remote-svn will link to libsvn, but will NOT link to Git. It\n> will simply use a thin wrapper to call compiled Git executables\n> (referred to as remote helper in article).\n\nIt should be possible to avoid calling any git executables (directly or \notherwise); git should call you with all the information you need.\n\n> The following resources will help build the various components:\n> 1. git_remote_helpers/git/git.py is a small remote helper written by\n> Sverre that wraps around git-fast-import. I plan to extend this to\n> wrap around git-fast-export as well.\n> 2. git-svn.perl contains a two-way mapping, parts of which I plan to implement.\n> 3. Thiago Macieira's svn-all-fast-export [2] has a complete SVN -> Git\n> mapping. I plan to take several ideas from the branch/ tag mapper in\n> repository.cpp.\n\nIf you're going to work in C, you should look at my Perforce helper. It's \nsuitable for mainline inclusion, due to using a free-as-in-beer, \nmade-available-without-license-terms C++ library for the Perforce side, \nbut may be a better model for a C remote helper than git.py is.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"137383","messageId":"f3271551003201519r61d3b9e5y83691ebb25da3534@mail.gmail.com","threadId":"23083","inReplyTo":"alpine.LNX.2.00.1003201724270.14365@iabervon.org","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-03-20T22:19:54Z","receivedAt":"2010-03-20T22:19:54Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"> The one thing I worry about is that you are proposing to wait a while\n> before submitting your changes upstream.  I would suggest pushing\n> whatever pieces work to contrib/ early on to get more feedback from\n> reviewers and testers.  (I am saying this selfishly, as a potential\n> tester.)\n\nOkay, I'll try to get patches integrated immediately then.\n\n> The structure for remote helpers should be that each foreign system has a\n> single helper which git can call with instructions on what to do (both for\n> foreign-to-git and for git-to-foreign operations). So 3 and 4 have to be\n> functions of the same program, and it's probably best for 2 and 5 and\n> maybe 1 to also be part of this program.\n\nRight. I only split it up for the purposes of illustration. 3 and 4\nwill be merged into a program called `git-remote-svn` that will\nautomatically be invoked when Git encounters an SVN remote. 2 and 5\nwill be merged into another program `svn-export-import` which can be\nthought of as the fusion of svn-fast-export and svn-fast-import.\n`git-remote-svn` will invoke it when necessary. And yeah, I don't know\nif I want to write the SVN client into `svn-export-import` or leave it\nas a separate program.\n\n> So the helper wouldn't be running git-fast-export or git-fast-import,\n> unless it was a helper for using git as the foreign system.\n\nAh. I just realized that :)\n\n> If you're going to work in C, you should look at my Perforce helper. It's\n> suitable for mainline inclusion, due to using a free-as-in-beer,\n> made-available-without-license-terms C++ library for the Perforce side,\n> but may be a better model for a C remote helper than git.py is.\n\nThanks. I'll have a look. git.py isn't very useful.\n\nRegards,\nRamkumar\n"},{"id":"137408","messageId":"f3271551003202236j2698a65bi3c7e29ee8a3cd1e1@mail.gmail.com","threadId":"23083","inReplyTo":"alpine.LNX.2.00.1003201724270.14365@iabervon.org","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-03-21T05:36:23Z","receivedAt":"2010-03-21T05:36:23Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\n> The structure for remote helpers should be that each foreign system has a\n> single helper which git can call with instructions on what to do (both for\n> foreign-to-git and for git-to-foreign operations). So 3 and 4 have to be\n> functions of the same program, and it's probably best for 2 and 5 and\n> maybe 1 to also be part of this program.\n\nI've attached a small image specifying the relationship between\nvarious components. I plan to include a more elaborate version of this\nin my final proposal. Is this what you had in mind?\n\nRegards,\nRamkumar\n"},{"id":"137413","messageId":"20100321074026.GD2557@m62s10.vlinux.de","threadId":"23083","inReplyTo":"f3271551003201334o4919cd47s44d06288b0d6068b@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2010-03-21T07:40:26Z","receivedAt":"2010-03-21T07:40:26Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Sun, Mar 21, 2010 at 02:04:40AM +0530, Ramkumar Ramachandra wrote:\n> Hi,\n> \n> I just prepared another revision of my proposal- I've tried to be\n> clearer about the objective, and included a timeline this time. Note\n> that I've also changed the name from native-git-svn to git-remote-svn,\n> as recommended by Sverre.\n> \n\n...\n \n> == The Technicalities ==\n> I've discussed the project with Sverre Rabbelier at length over email.\n> The plan is to build component-wise. The distinct components are:\n> 1. An SVN client that uses libsvn to fetch/ push revisions to a remote\n> SVN repository.\n> 2. An exporter for SVN repositories, which will extract all the\n> relevant revision history and metadata to import into Git.\n\nIsn't that called an importer? At least if I am looking from the Git side\nit imports a SVN repository.\n\n> 3. A remote helper for Git that takes the data from this SVN exporter,\n> and uses git-fast-import to create corresponding commits in Git.\n\nDito.\n\n> 4. Another remote helper to export commit data and metadata from Git\n> to import into SVN.\n ^^^^^^\n export\n\n> 5. An importer for SVN, which will create revisions in SVN\n ^^^^^^^\n exporter\n> corresponding to commits in Git.\n\nI have to admit, I like your proposal. Your first points sound a little bit too\nnegative for my taste considering git svn serves me well on my day job, but\nfair enough.\n\n--\nPeter\n"},{"id":"137414","messageId":"alpine.DEB.1.00.1003211125290.7596@pacific.mpi-cbg.de","threadId":"23083","inReplyTo":"20100320210406.GA29899@progeny.tock","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-03-21T10:26:51Z","receivedAt":"2010-03-21T10:26:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 20 Mar 2010, Jonathan Nieder wrote:\n\n> Ramkumar Ramachandra wrote:\n> \n> > == Timeline ==\n> \n> The one thing I worry about is that you are proposing to wait a while \n> before submitting your changes upstream. I would suggest pushing \n> whatever pieces work to contrib/ early on to get more feedback from \n> reviewers and testers. (I am saying this selfishly, as a potential \n> tester.)\n\nI would rather have frequent updates about the progress on the mailing \nlist, and a long-running branch in which the code is developed, only \nrebasing to Junio's next/pu when absolutely necessary.\n\nAfter all, it would be additional work to put it first into contrib/ and \nthen to integrate it fully into git.git.\n\nCiao,\nDscho\n"},{"id":"137436","messageId":"20100321110807.GA24016@progeny.tock","threadId":"23083","inReplyTo":"alpine.DEB.1.00.1003211125290.7596@pacific.mpi-cbg.de","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-03-21T11:08:08Z","receivedAt":"2010-03-21T11:08:08Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJohannes Schindelin wrote:\n> On Sat, 20 Mar 2010, Jonathan Nieder wrote:\n>> Ramkumar Ramachandra wrote:\n\n>>> == Timeline ==\n>>\n>> The one thing I worry about is that you are proposing to wait a while \n>> before submitting your changes upstream. I would suggest pushing \n>> whatever pieces work to contrib/ early on to get more feedback from \n>> reviewers and testers. (I am saying this selfishly, as a potential \n>> tester.)\n>\n> I would rather have frequent updates about the progress on the mailing \n> list, and a long-running branch in which the code is developed, only \n> rebasing to Junio's next/pu when absolutely necessary.\n\nYou are usually right about this kind of thing, so I will not disagree\ntoo strongly.\n\nBut I will say: I think this was a mistake in the git sequencer\nproject. Stephan did excellent work both on and off list, and I think\nit is a shame that as little of his code reached mainline by the end\nof the summer as did. I imagine that submitting bit by bit would have\nrequired a different approach: maybe a sequencer--helper that would\ngradually grow to absorb more of the functionality of the prototype\nscript. Harder, but the result would be working code.\n\nNow it is hard enough to merge current master into the sequencer\nbranch...\n\nWhether to use stable topic branches or rebased-against-master patch\nseries as the means of submission is a decision that matters less to me.\n(I prefer the former.)\n\n> After all, it would be additional work to put it first into contrib/ and \n> then to integrate it fully into git.git.\n\nI am not sure I understand this point. Are you saying the change in\nfilenames would be problematic?\n\nCurious,\nJonathan\n"},{"id":"137439","messageId":"alpine.DEB.1.00.1003211236050.7596@pacific.mpi-cbg.de","threadId":"23083","inReplyTo":"20100321110807.GA24016@progeny.tock","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-03-21T11:47:58Z","receivedAt":"2010-03-21T11:47:58Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 21 Mar 2010, Jonathan Nieder wrote:\n\n> Johannes Schindelin wrote:\n> > On Sat, 20 Mar 2010, Jonathan Nieder wrote:\n> >> Ramkumar Ramachandra wrote:\n> \n> >>> == Timeline ==\n> >>\n> >> The one thing I worry about is that you are proposing to wait a while \n> >> before submitting your changes upstream. I would suggest pushing \n> >> whatever pieces work to contrib/ early on to get more feedback from \n> >> reviewers and testers. (I am saying this selfishly, as a potential \n> >> tester.)\n> >\n> > I would rather have frequent updates about the progress on the mailing \n> > list, and a long-running branch in which the code is developed, only \n> > rebasing to Junio's next/pu when absolutely necessary.\n> \n> You are usually right about this kind of thing, so I will not disagree\n> too strongly.\n> \n> But I will say: I think this was a mistake in the git sequencer project.\n\nThe mistakes in the sequencer project were more than this. Not only was \nthe development of the branch almost invisible, when it was done, it was \nbasically with a comment \"here it is, take it or leave it\", and good \nsuggestions as to improve the code went unheeded.\n\nThat's why I suggested frequent progress reports on the mailing list. \nOf course, these reports should only be commented upon by people who are \nfully informed about the project, they should not be invitations to \neverybody and her dog to distract the student by putting in unreasonable \nor uninformed wishes.\n\n> Now it is hard enough to merge current master into the sequencer \n> branch...\n\nThe problem is not the merging. The problem is that the code is not in a \nform I (or certain others) want to see in git.git.\n\n> > After all, it would be additional work to put it first into contrib/ \n> > and then to integrate it fully into git.git.\n> \n> I am not sure I understand this point. Are you saying the change in \n> filenames would be problematic?\n\nI say that distracting the student from the real task is problematic. The \nreal task does not involve putting the code into contrib/ first, and then \nmove it into the final location.\n\nPersonally, I would have little problems just adding the remote and \nchecking out the branch, just to test the thing after I got a promising \nprogress report. And I think those who are truly interested in \ngit-remote-svn will have little problems, either. The important part would \nbe the visible progress (i.e. mails by the student to this list).\n\nCiao,\nDscho\n"},{"id":"137440","messageId":"f3271551003210525l761cf36eh69cdfddf4e645ef3@mail.gmail.com","threadId":"23083","inReplyTo":"alpine.DEB.1.00.1003211236050.7596@pacific.mpi-cbg.de","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-03-21T12:25:02Z","receivedAt":"2010-03-21T12:25:02Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\n> Personally, I would have little problems just adding the remote and\n> checking out the branch, just to test the thing after I got a promising\n> progress report. And I think those who are truly interested in\n> git-remote-svn will have little problems, either. The important part would\n> be the visible progress (i.e. mails by the student to this list).\n\nThanks for the elaborate explanation. The way I see it, there are two\nextreme situations I must avoid. The first is being opaque for the\nrisk of not being able to integrate it into git.git at the end of the\nsummer term. The other extreme is worrying so much about the\nintegration of each little bit that the project keeps getting\ndetracted, and eventually loses focus. To strike a balance, I will\npost progress reports to the mailing list (atleast) once a week, and\nkeep a public development branch for myself. Occasionally, it might\nhelp to post patches for small components of the project with\nunittests to get a wider test audience.\n\nRamkumar\n"},{"id":"137441","messageId":"alpine.DEB.1.00.1003211331160.7596@pacific.mpi-cbg.de","threadId":"23083","inReplyTo":"f3271551003210525l761cf36eh69cdfddf4e645ef3@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-03-21T12:31:41Z","receivedAt":"2010-03-21T12:31:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 21 Mar 2010, Ramkumar Ramachandra wrote:\n\n> Dscho wrote:\n> \n> > Personally, I would have little problems just adding the remote and \n> > checking out the branch, just to test the thing after I got a \n> > promising progress report. And I think those who are truly interested \n> > in git-remote-svn will have little problems, either. The important \n> > part would be the visible progress (i.e. mails by the student to this \n> > list).\n> \n> Thanks for the elaborate explanation. The way I see it, there are two \n> extreme situations I must avoid. The first is being opaque for the risk \n> of not being able to integrate it into git.git at the end of the summer \n> term. The other extreme is worrying so much about the integration of \n> each little bit that the project keeps getting detracted, and eventually \n> loses focus. To strike a balance, I will post progress reports to the \n> mailing list (atleast) once a week, and keep a public development branch \n> for myself. Occasionally, it might help to post patches for small \n> components of the project with unittests to get a wider test audience.\n\nThat sounds very good!\n\nCiao,\nDscho\n"},{"id":"137442","messageId":"fabb9a1e1003210536n5272ad68kf730d8263fe4c379@mail.gmail.com","threadId":"23083","inReplyTo":"f3271551003210525l761cf36eh69cdfddf4e645ef3@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-03-21T12:36:11Z","receivedAt":"2010-03-21T12:36:11Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Sun, Mar 21, 2010 at 13:25, Ramkumar Ramachandra wrote:\n> Occasionally, it might help to post patches for small components\n> of the project with unittests to get a wider test audience.\n\nI suggest that (and this is a suggestion for all git GSoC projects)\nthat all students are required to post a weekly status update to the\nmailing list. If they then prefix those mails with [GSoC update] it is\n1) easy to filter out these emails for those who are not interested in\nthem and 2) easy later on to get a quick overview of who did what\nwhen, by searching for all [GSoC update] emails. At first these emails\ncan just be a description of what was done in the past week, which\ndesign decisions were made (and why), and what the current status of\nthe project is. Later on these should be complemented by patches to\nthe git list (prefixed with [RFC/GSoC/PATCH] or such) with the\nprogress of the student so far.\n\nIn this particular case I think it'd be a good idea to start sending\npatches around 3-4 weeks into the project, since by June 20 you hope\nto have something minimally usable. I reckon it would be good to keep\nthese patches in pu to give them wider exposure, and to start merging\nthem to next as appropriate. For example, as soon as there is full\nread support that would be a good time to merge to next to allow more\npeople to give it a try.\n\nJunio, how do you feel about keeping these (most likely\nfairly-unstable) GSoC patches in pu? I think it would be a great\nmotivation for our students (look, I've got my work into pu!), and\nit'd be a great way to make it easy for everybody else to try out the\nwork of our students.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"137452","messageId":"m3ljdlk4nw.fsf_-_@localhost.localdomain","threadId":"23083","inReplyTo":"alpine.DEB.1.00.1003211236050.7596@pacific.mpi-cbg.de","subject":"Best example of GSoC student participation (was: Re: native-git-svn: A Summer of Code 2010 proposal)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-03-21T16:43:38Z","receivedAt":"2010-03-21T16:43:38Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin writes:\n\n> The mistakes in the sequencer project were more than this. Not only was \n> the development of the branch almost invisible, when it was done, it was \n> basically with a comment \"here it is, take it or leave it\", and good \n> suggestions as to improve the code went unheeded.\n> \n> That's why I suggested frequent progress reports on the mailing list. \n> Of course, these reports should only be commented upon by people who are \n> fully informed about the project, they should not be invitations to \n> everybody and her dog to distract the student by putting in unreasonable \n> or uninformed wishes.\n\nBy the way, which of the former GSoC students (and for which project)\ncan serve as the best example of good interaction with the git\ncommunity and with GSoC mentors?\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"137455","messageId":"20100321170808.GA15512@LK-Perkele-V2.elisa-laajakaista.fi","threadId":"23083","inReplyTo":"alpine.LNX.2.00.1003201724270.14365@iabervon.org","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Ilari Liusvaara","fromEmail":"ilari.liusvaara@elisanet.fi","sentAt":"2010-03-21T17:08:08Z","receivedAt":"2010-03-21T17:08:08Z","isPatch":false,"sender":{"key":"ilari.liusvaara@elisanet.fi","avatar":null},"body":"On Sat, Mar 20, 2010 at 05:58:34PM -0400, Daniel Barkalow wrote:\n> On Sun, 21 Mar 2010, Ramkumar Ramachandra wrote:\n> \n> > Due to a licensing conflict, the details of which can be found here\n> > [1], git-remote-svn will link to libsvn, but will NOT link to Git. It\n> > will simply use a thin wrapper to call compiled Git executables\n> > (referred to as remote helper in article).\n> \n> It should be possible to avoid calling any git executables (directly or \n> otherwise); git should call you with all the information you need.\n\nDon't know about importer modes, but in native connection mode it is\npossible to avoid calling or linking to git in any way (been there, done\nthat).\n\nAnd if one doesn't need git APIs, its completely possible to avoid\nlinking into git (this may mean some mode coding effor however).\n\n-Ilari\n"},{"id":"137458","messageId":"alpine.DEB.1.00.1003211821110.7596@pacific.mpi-cbg.de","threadId":"23083","inReplyTo":"m3ljdlk4nw.fsf_-_@localhost.localdomain","subject":"Re: Best example of GSoC student participation","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-03-21T17:27:26Z","receivedAt":"2010-03-21T17:27:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 21 Mar 2010, Jakub Narebski wrote:\n\n> Johannes Schindelin writes:\n> \n> > The mistakes in the sequencer project were more than this. Not only was \n> > the development of the branch almost invisible, when it was done, it was \n> > basically with a comment \"here it is, take it or leave it\", and good \n> > suggestions as to improve the code went unheeded.\n> > \n> > That's why I suggested frequent progress reports on the mailing list. \n> > Of course, these reports should only be commented upon by people who are \n> > fully informed about the project, they should not be invitations to \n> > everybody and her dog to distract the student by putting in unreasonable \n> > or uninformed wishes.\n> \n> By the way, which of the former GSoC students (and for which project)\n> can serve as the best example of good interaction with the git\n> community and with GSoC mentors?\n\nI think the best examples we have to show are\n\n- Sverre (even if his work is not in git.git; Junio thought that the \n project could gain more visibility outside of Git, but that had rather \n the opposite effect), who interacted with the Git community and with his \n mentor rather well,\n\n- Marek, who did a good job with the push support in JGit/EGit (even if he \n did not communicate with the community frequently, he did often enough, \n and listened to advice), and of course\n\n- Miklos, who was already known on the Git mailing list before getting \n really involved through the Summer of Code.\n\nCiao,\nDscho\n"},{"id":"137466","messageId":"20100321175820.GA26174@progeny.tock","threadId":"23083","inReplyTo":"f3271551003210525l761cf36eh69cdfddf4e645ef3@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-03-21T17:58:20Z","receivedAt":"2010-03-21T17:58:20Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n> Thanks for the elaborate explanation. The way I see it, there are two\n> extreme situations I must avoid. The first is being opaque for the\n> risk of not being able to integrate it into git.git at the end of the\n> summer term. The other extreme is worrying so much about the\n> integration of each little bit that the project keeps getting\n> detracted, and eventually loses focus. To strike a balance, I will\n> post progress reports to the mailing list (atleast) once a week, and\n> keep a public development branch for myself. Occasionally, it might\n> help to post patches for small components of the project with\n> unittests to get a wider test audience.\n\nSounds great to me, too. It seems you understand the issues well.\n\nCheers,\nJonathan\n"},{"id":"137488","messageId":"alpine.LNX.2.00.1003211837300.14365@iabervon.org","threadId":"23083","inReplyTo":"f3271551003202236j2698a65bi3c7e29ee8a3cd1e1@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2010-03-21T22:56:03Z","receivedAt":"2010-03-21T22:56:03Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 21 Mar 2010, Ramkumar Ramachandra wrote:\n\n> Hi,\n> \n> > The structure for remote helpers should be that each foreign system has a\n> > single helper which git can call with instructions on what to do (both for\n> > foreign-to-git and for git-to-foreign operations). So 3 and 4 have to be\n> > functions of the same program, and it's probably best for 2 and 5 and\n> > maybe 1 to also be part of this program.\n> \n> I've attached a small image specifying the relationship between\n> various components. I plan to include a more elaborate version of this\n> in my final proposal. Is this what you had in mind?\n\nMostly, except that I think it should be possible to avoid having \ngit-remote-svn actually link to the git core, because the git core should \nbe taking care of everything git-specific for you. Of course, the git core \nalso provides a bunch of useful C library code that you may want to use, \nsuch as a nice string buffer implementation, so you may want to link to \ngit even if you don't actually need it, if licenses are suitable and it \nwould be convenient.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"137494","messageId":"alpine.DEB.2.00.1003211643470.21433@narbuckle.genericorp.net","threadId":"23083","inReplyTo":"32541b131003191430ld0eaa9cw1d2aac08cff15682@mail.gmail.com","subject":"Re: Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Dave Olszewski","fromEmail":"cxreg@pobox.com","sentAt":"2010-03-21T23:51:28Z","receivedAt":"2010-03-21T23:51:28Z","isPatch":false,"sender":{"key":"cxreg@pobox.com","avatar":"https://avatars.githubusercontent.com/u/55474?v=4"},"body":"On Fri, 19 Mar 2010, Avery Pennarun wrote:\n\n> For example, I'd be very happy to learn that your new design would\n> allow two people to independently pull from svn://, do work in their\n> respective copies of the git repositories, branch and merge all day\n> long, pull from each other, and then push back to svn without a)\n> making a mess of the svn repo and causing zillions of conflicts, or b)\n> linearizing history and losing git's complex DAG.\n>\n> In the current version of git-svn this is very hard. 'git svn dcommit'\n> generates entirely new git commit objects corresponding to the ones\n> that were created in svn... but which nevertheless have your merge\n> history included, which is awesome. But if a new person clones the\n> svn repo from scratch, he will end up with git commits corresponding\n> to those same ones from svn, but *without* the merge history, and\n> therefore with different commit ids, and which therefore prevent\n> push/pulling between other people who have cloned the repo.\n\nI've been working on a script that does 2-way integration with an\nupstream CVS repo, using git-cvsimport and git-cvsexportcommit to do the\ndifficult parts.\n\nI solved this problem you mention by rebasing in both directions onto\ndetached HEADs and exporting the result, meaning that the history is\npermanently diverged from a DAG standpoint. Of course, over time, the\nrebase would become increasingly messy and horrible, so I created a\ncouple of placeholder refs which are updated after the import/export is\nfinished. These mark the last time it was done, and allow you only to\nattempt to apply the commits which are new on each side.\n\nIt's still very green and I've already worked though a number of pretty\nhairy problems, so I'm not going to say it's a bulletproof solution.\nBut it does work.\n\n Dave\n"},{"id":"137496","messageId":"alpine.LNX.2.00.1003212011280.14365@iabervon.org","threadId":"23083","inReplyTo":"f3271551003210525l761cf36eh69cdfddf4e645ef3@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2010-03-22T00:33:47Z","receivedAt":"2010-03-22T00:33:47Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 21 Mar 2010, Ramkumar Ramachandra wrote:\n\n> Hi,\n> \n> > Personally, I would have little problems just adding the remote and\n> > checking out the branch, just to test the thing after I got a promising\n> > progress report. And I think those who are truly interested in\n> > git-remote-svn will have little problems, either. The important part would\n> > be the visible progress (i.e. mails by the student to this list).\n> \n> Thanks for the elaborate explanation. The way I see it, there are two\n> extreme situations I must avoid. The first is being opaque for the\n> risk of not being able to integrate it into git.git at the end of the\n> summer term. The other extreme is worrying so much about the\n> integration of each little bit that the project keeps getting\n> detracted, and eventually loses focus. To strike a balance, I will\n> post progress reports to the mailing list (atleast) once a week, and\n> keep a public development branch for myself. Occasionally, it might\n> help to post patches for small components of the project with\n> unittests to get a wider test audience.\n\nOne thing to keep in mind is that you'll get review at a slower rate than \nyou'll make progress, and you'll need progress, review, and fixes to get \nintegration. This means that the optimal pattern is to post incomplete \nthings (marked [RFC PATCH]) when you've got enough there to show where \nyou're going and you think the quality of the code you have is pretty \ngood. Your patches go out, and you work on the next step while other \npeople find them, read them, write comments, and you get the comments. \nThen you incorporate the changes for the comments into the next round (or \nyou acknowledge the need for changes, but defer them to the third round, \nif you've got a second round ready). The thing that really stalls a \nproject, either in the middle or at the end, is when you can't do anything \nwhile you wait for a round-trip exchange with reviewers (or multiple \nround-trips, if the comments are non-trivial and you need further \nexplanation or to propose alternatives).\n\nThe longer you anticipate between sending the patches out and having them \nincluded, and the busier you can stay in that time, the better. \nOverlapping does mean that you end up reworking later patches, but (unless \nyou can save up hours of work) it's better to have patches to rework than \nto be starting from scratch at that point, and it's better to know what \nyou'll have to rework as early as is feasible.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"137504","messageId":"201003220341.38918.chriscool@tuxfamily.org","threadId":"23083","inReplyTo":"alpine.LNX.2.00.1003212011280.14365@iabervon.org","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2010-03-22T02:41:38Z","receivedAt":"2010-03-22T02:41:38Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Monday 22 March 2010 01:33:47 Daniel Barkalow wrote:\n> One thing to keep in mind is that you'll get review at a slower rate than\n> you'll make progress, and you'll need progress, review, and fixes to get\n> integration. This means that the optimal pattern is to post incomplete\n> things (marked [RFC PATCH]) when you've got enough there to show where\n> you're going and you think the quality of the code you have is pretty\n> good. Your patches go out, and you work on the next step while other\n> people find them, read them, write comments, and you get the comments.\n> Then you incorporate the changes for the comments into the next round (or\n> you acknowledge the need for changes, but defer them to the third round,\n> if you've got a second round ready). \n\nI agree but I think that it should be stressed that a GSoC project should be \nsplit into many milestones and that each milestone should be in itself a \nworthwhile improvement to the previous state. So that when a milestone is \nreached, the code can be sent to the list for review (marked [RFC PATCH]) and \nthen improved and sent again as many times as needed (marked with v1, v2, ...) \nto get it merged.\n\nAnd it is important to understand that responding to reviews and doing \nwhatever is needed to get the code for the first milestones merged _is more \nimportant_ than developing code for the next milestones.\n\nBecause it's much better for everyone at the end of the GSoC if only half of \nthe project is finished but merged, rather than if all the project is \"finished\" \nbut nothing can be merged.\n\nThe code that can't be merged will rust very fast and will probably need quite \nsome work that unfortunately few people may want or be able to do fast enough \nafter the end of the GSoC. And that means that basically the work that has \nbeen done will be mostly lost which is very _very_ frustrating for students, \nmentors, reviewers and everyone involved...\n\nBest regards,\nChristian.\n"},{"id":"137511","messageId":"f3271551003212049r1139d6b4x279c6803cc4c7fe2@mail.gmail.com","threadId":"23083","inReplyTo":"201003220341.38918.chriscool@tuxfamily.org","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-03-22T03:49:54Z","receivedAt":"2010-03-22T03:49:54Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"> Don't know about importer modes, but in native connection mode it is\n> possible to avoid calling or linking to git in any way (been there, done\n> that).\n\n> Mostly, except that I think it should be possible to avoid having\n> git-remote-svn actually link to the git core, because the git core should\n> be taking care of everything git-specific for you. Of course, the git core\n> also provides a bunch of useful C library code that you may want to use,\n> such as a nice string buffer implementation, so you may want to link to\n> git even if you don't actually need it, if licenses are suitable and it\n> would be convenient.\n\nAs of this point, I'm undecided about which parts of Git Core to link\nto, if at all. I'll try to avoid linking, but I'll do whatever is most\nconvenient within the bounds of the license as I write the remote\nhelper.\n\n> I solved this problem you mention by rebasing in both directions onto\n> detached HEADs and exporting the result, meaning that the history is\n> permanently diverged from a DAG standpoint.  Of course, over time, the\n> rebase would become increasingly messy and horrible, so I created a\n> couple of placeholder refs which are updated after the import/export is\n> finished.  These mark the last time it was done, and allow you only to\n> attempt to apply the commits which are new on each side.\n\nAh. Could you please post a link to your code?\n\n> Because it's much better for everyone at the end of the GSoC if only half of\n> the project is finished but merged, rather than if all the project is \"finished\"\n> but nothing can be merged.\n\nRight. I'll merge the whole thing in 3-4 phases then.\n\n-- Ram\n"},{"id":"137542","messageId":"alpine.DEB.1.00.1003221231540.7596@pacific.mpi-cbg.de","threadId":"23083","inReplyTo":"f3271551003212049r1139d6b4x279c6803cc4c7fe2@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-03-22T11:33:57Z","receivedAt":"2010-03-22T11:33:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ram,\n\nOn Mon, 22 Mar 2010, Ramkumar Ramachandra wrote:\n\n> > Don't know about importer modes, but in native connection mode it is \n> > possible to avoid calling or linking to git in any way (been there, \n> > done that).\n> \n> > Mostly, except that I think it should be possible to avoid having \n> > git-remote-svn actually link to the git core, because the git core \n> > should be taking care of everything git-specific for you. Of course, \n> > the git core also provides a bunch of useful C library code that you \n> > may want to use, such as a nice string buffer implementation, so you \n> > may want to link to git even if you don't actually need it, if \n> > licenses are suitable and it would be convenient.\n> \n> As of this point, I'm undecided about which parts of Git Core to link \n> to, if at all. I'll try to avoid linking, but I'll do whatever is most \n> convenient within the bounds of the license as I write the remote \n> helper.\n\nAFAICT the git-remote idea is to use a text protocol (which may lend \nitself to be copied by Mercurial at some stage, a clear sign that we did \nsomething well when that happens).\n\n> > Because it's much better for everyone at the end of the GSoC if only \n> > half of the project is finished but merged, rather than if all the \n> > project is \"finished\" but nothing can be merged.\n> \n> Right. I'll merge the whole thing in 3-4 phases then.\n\nI am sure that Sverre will be of tremendous help to decide when is the \nopportune moment to show off your code.\n\nCiao,\nDscho\n"},{"id":"137581","messageId":"alpine.DEB.1.00.1003222050470.7596@pacific.mpi-cbg.de","threadId":"23083","inReplyTo":"f3271551003220643j3a726d09o2d3a078292fd8bf6@mail.gmail.com","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-03-22T19:52:34Z","receivedAt":"2010-03-22T19:52:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 22 Mar 2010, Ramkumar Ramachandra wrote:\n\n> Thank you all for the feedback. Here's an updated version of the diagram \n> I posted earlier with some corrections. I've assumed that I won't be \n> linking to Git core at all.\n\nThe flow looks good (although I had to jump through hoops to look at it, I \nam reading mails via ssh'ed text console).\n\nI have to admit that I would prefer a more detailed timeline, if only to \nshow how well you understand the individual requirements of trying to \ninterpret the fast-import protocol in an svn context.\n\nCiao,\nDscho\n"},{"id":"137613","messageId":"f3271551003230049u6cd5b2ft811acd6ebfad8471@mail.gmail.com","threadId":"23083","inReplyTo":"alpine.DEB.1.00.1003222050470.7596@pacific.mpi-cbg.de","subject":"Re: native-git-svn: A Summer of Code 2010 proposal","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-03-23T07:49:39Z","receivedAt":"2010-03-23T07:49:39Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\n> The flow looks good (although I had to jump through hoops to look at it, I\n> am reading mails via ssh'ed text console).\n\nIn that case, I shouldn't put any crucial information in the figure\nlike the timeline, in the interest of several reviewers who might be\nin a similar position.\n\n> I have to admit that I would prefer a more detailed timeline, if only to\n> show how well you understand the individual requirements of trying to\n> interpret the fast-import protocol in an svn context.\n\nIs the timeline in the text of the proposal detailed enough? I'm\nplanning to submit that, and remove the one in the figure.\n\n-- Ram\n"}]}