Re: GSOC Proposal draft: git-remote-svn

From: Florian Achleitner <florian.achleitner2.6.31@gmail.com>
Date: Apr 18, 2012, 20:16 UTC
Message-ID: <16489638.QvpMpkdxMd@flomedio>
In-Reply-To: <20120410171707.GA3869@burratino>

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 ..

Show 5 quoted lines

> 
>  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