On Sunday 22 July 2012 16:43:33 Jonathan Nieder wrote: > Hi, > > Florian Achleitner wrote: > > After several mailing iterations, showing me that I was wrong, I found > > what > > the right point is, namely that the remote helper writes references to a > > really private dir in refs/<remote name>/, it doesn't touch anything else, > > and by advertising the 'refspec' capability, git-fetch knows where the > > private refs are and updates non-private references according to the > > fetch refspec in some post-processing in store_updated_refs. > > Right, that's fine. And you did a fine job of navigating the existing > documentation (which could be improved, hint hint). > > What I am more concerned about is that you had code you sent a while > ago for review, that this would have been obvious to David, Ram, > Dmitry, or me if we had seen it, and yet none of us gave you that > help. We are failing at _our_ job of giving you prompt advice and > instead you have had to work on your own. > > Isn't it likely that there are multiple other bugs like that which > still haven't been fixed? > > That's why I think we need to get into a habit of giving and getting > feedback quickly and incrementally improving work. Soon, before the > summer ends. > > [...] > > >> [23:01:10] <jrnieder> and it should not be named remote-svn, since we > > > > haven't pinned down details about the svn:: conversion yet. That's why > > Dmitry's was called git-remote-svn-alpha) > > > > Ok. Why is that important? I think if it's not called remote-svn git > > doesn't fid it as a helper for the 'svn' protocol. > > It finds it as a helper for the 'svn-alpha' protocol instead. > > The point is that when I perform the following steps: > > git clone svn://path/to/remote/repo > > ... wait a day, update git > > cd repo > git pull > > nobody would expect the result to be a non-fast-forward update caused > by the details of svn-to-git conversion changing. Using a name like > testsvn or svn-alpha would help in managing expectations --- the > remote helper is meant for experimentation for now and not meant to be > something people can rely on for collaboration.
Ok, that makes sense. Renaming is easily done! > > > I wrote a small simulation script in python that mimics svnrdumps > > behaviour by replaying an existing svn dump file from a start rev up to > > an end rev to test incremental imports. I use it together with a little > > testrepo shell script. Will need to bring that into t/ later, after > > figuring out how the test framework works. As it's not finished it's not > > published. > > Sounds neat --- how can one try it out? I'll send a patch ... > > > Incremental import: > > By reading the latest svn revision number from a note attached to the > > private master ref, it starts future imports from the next svn revision. > > That basically works well. > > It doesn't reuse mark files. What's the point of reusing them? Dmitry's > > svn- alpha did that. > > All I need to know is the revision to start from and the branch i want to > > add commits to, right? It now simply reads that from the note. > > The marks are used to handle copyfrom operations referring to older > revisions. Are you sure you want to abandon them? Can you explain a > little more about your plan? Ok, that makes sense. I didn't need the marks for incremental import. But to evaluate the copyfrom props we need some revision->sha1 mapping. I just added the options to save and import marks to fast-import's command line. If the file is missing, it will need to be generated from the notes, or the whole history will be reimported. But when I fetch from a git repo that imported from svn, the notes are not fetched automatically. In this case I currently loose marks and notes. What can I do? Florian -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
