On Tuesday 10 April 2012 12:17:07 Jonathan Nieder wrote: > In other words, in the above list the strategy is: > > 1. First convert the remote helper to C so it doesn't have to be > translated again later. Store rev <--> commit mappings using marks and notes. Store svn metadata. > > 2. Teach the remote helper to import a single project from a > repository that houses multiple projects (i.e., path limiting). I would plan to have this until the mid-term. From that point my summer holidays start .. > > 3. Teach the remote helper to split an imported project that uses > the standard layout into branches (an application of the code > from (2)). This complicates the scheme for mapping between > Subversion revision numbers and git commit ids. Read ambigouos branches/tags from SBL. > > 4. Teach the SVN dumpfile to fast-import stream converter not to > lose the information that is needed in order to get parenthood > information. This means actually saving svn:copyfrom properties. (right?) > > 5. Use the information from step (4) to get parenthood right for a > project split into branches. .. and using svn:copyfrom properties. (right?) > > 6. Getting the second parent right (i.e., merges). I mentioned > this for fun but I don't expect there to be time for it. I think this needs a little morge discussion, let's do this if it's the time. mergeinfo stores a list of revs merged for a file. This looks like a list of git cherry-picks to me .. > > Does that seem right, or does it need tweaks? How long would each > step take? Can the steps be subdivided into smaller steps? What do you think? I will finally add this strategy to the proposal. -- Florian -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html