Re: GSOC Proposal draft: git-remote-svn

[Florian Achleitner <florian.achleitner2.6.31@gmail.com>]

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