git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC PATCH 0/3] Towards a Git-to-SVN bridge

From
Ramkumar Ramachandra <artagnon@gmail.com>
Date
Jan 15, 2011, 07:43 UTC
Message-ID
<20110115074327.GA9277@kytes>
In-Reply-To
<20110115072211.GB25253@burratino>
Hi Jonathan,
Jonathan Nieder writes:
Show 8 quoted lines
> Ramkumar Ramachandra wrote:
> 
> > Over the last couple of days, I've been working on a parser that
> > converts a fast-import stream into a SVN dumpfile. So far, it's very
> > rough and works minimally for some common fast-import
> > commands.
> 
> Some early questions:

Thanks for raising these questions. People interested in the project should find this useful.

>  - what are the design goals?  Is this meant to be super fast?
>    Robust?  Simple?  Why should I be excited about it?[1]

I want it to be a lot like current svn-fe: as you can see, I've re-used many parsing ideas from it. It has to be atleast as fast as svnrdump, because I don't want it to bottleneck in the remote helper pipeline. It has to be simple because it'll give rise to other simple remote helpers- all the complexity has to be offloaded onto the lower layers like fast-import/ fast-export, and not onto the developer of the remote helper.

>  - what subset of fast-import commands is supported?  Is it well
>    enough defined to make a manpage?

Currently, it supports just "commit", "blob", "author", "committer" and "mark" that appear after a blob. It should support more commands soon enough- this implementation is just a proof of concept. Also, Instead of giving it the ability to parse /any/ valid fast-import stream, I want to simply focus on parsing the stream produced by git fast-export. That should explain why I'm trying to patch git fast-export primarily.

>  - does this produce v2 or v3 dumpfiles?

This is one issue I haven't thought about fully yet. I'm currently thinking of generating a non-deltified dumpfile v3 -- something that svnrdump will accept. Generating deltas might be an unnecessary overhead- but as you pointed out yesterday, that clearly needs more thought.

>  - why would I use this instead of git2svn?  Does git2svn do anything
>    this will not eventually be able to do?  (Not a trick question ---
>    I don't have enough experience with git2svn to tell its strengths
>    and weaknesses.)

git2svn persists blobs in-memory. It's written in Perl and it's slow. I thought we needed something nicer to be used with a remote helper, and started writing svn-fi.

> > I've decided to try re-implementing fast-export
> > to eliminate blob marks
> 
> Hopefully "re-implement" means "patch" here. :)
Yep. Just a big one :)
> I can comment on the code but it's probably better if I have a sense
> of the design first (in any event, thanks for sending it).

I haven't had time to clean up the code. Note that it "just works" at the moment- yes, it's already very very fast :) However, I'm going to stall the branch and work on fast-export-inline for now.

-- Ram
Previous: Jonathan Nieder
Message 8 of 8 in “Towards a Git-to-SVN bridge”
  1. 0/3 Towards a Git-to-SVN bridgeRamkumar Ramachandra, Jan 15, 2011
  2. 1/3 date: Expose the time_to_tm functionRamkumar Ramachandra, Jan 15, 2011
  3. 2/3 vcs-svn: Start working on the dumpfile producerRamkumar Ramachandra, Jan 15, 2011
  4. Peter BaumannJan 15, 2011
  5. Ramkumar RamachandraJan 15, 2011
  6. 3/3 Build an svn-fi target in contrib/svn-feRamkumar Ramachandra, Jan 15, 2011
  7. Jonathan NiederJan 15, 2011
  8. Ramkumar RamachandraJan 15, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.