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

Re: [PATCH 4/5] fast-export: Introduce --inline-blobs

From
Ramkumar Ramachandra <artagnon@gmail.com>
Date
Jan 22, 2011, 09:24 UTC
Message-ID
<20110122092416.GA7827@kytes>
In-Reply-To
<1295531623.4298.26.camel@drew-northup.unet.maine.edu>
Hi Drew,
Drew Northup writes:
Show 32 quoted lines
> On Thu, 2011-01-20 at 10:20 +0530, Ramkumar Ramachandra wrote:
> > Hi,
> > Jonathan Nieder writes:
> > > Junio C Hamano wrote:
> > > > Ramkumar Ramachandra <artagnon@gmail.com> writes:
> > > > Just thinking aloud, but is it possible to write a filter that converts an
> > > > arbitrary G-F-I stream with referenced blobs into a G-F-I stream without
> > > > referenced blobs by inlining all the blobs?
> > > 
> > > to avoid complexity in the svn fast-import backend itself.
> > > (Complicating detail: such a filter would presumably take responsibility
> > > for --export-marks, so it might want a way to retrieve commit marks
> > > from its downstream.)
> > 
> > This filter will need to persist every blob for the entire lifetime of
> > the program. We can't possibly do it in-memory, so we have to find
> > some way to persist them on-disk and retrieve them very
> > quickly. Jonathan suggested using something like ToyoCabinet earlier-
> > I'll start working and see what I come up with.
> 
> Is it worth including the extra dependency? Most systems that I'm in
> frequent contact with already have some lightweight BDB implementation
> already. I don't currently know of any with TokyoCabinet (or
> KyotoCabinet for that matter) already in place. Besides, if all you're
> doing is persisting blobs that you're likely to write out to disk
> eventually anyway you might as well just do so once you have them and
> keep an "index" (not to be confused with the Git Index, just lacking a
> better word right now) of what you have in some standard in-memory
> format (a heap?). From there you can build each commit into the Git
> Index in the proper order once you have the required parts for
> each--perhaps even re-using the blobs you've already dumped to disk
> (mv'ing them or something).

Agreed. I wouldn't like to introduce an extra dependency either. I was talking about using it for prototyping- if the final version includes an extra dependency, it's unlikely to get merged into git.git :) The final design will probably use an in-memory B+ tree, but I haven't thought about that hard enough.

-- Ram
Previous: Drew NorthupNext: Jonathan Nieder
Message 14 of 18 in “Towards a Git-to-SVN bridge”
  1. 0/5 Towards a Git-to-SVN bridgeRamkumar Ramachandra, Jan 19, 2011
  2. 1/5 date: Expose the time_to_tm functionRamkumar Ramachandra, Jan 19, 2011
  3. 2/5 vcs-svn: Start working on the dumpfile producerRamkumar Ramachandra, Jan 19, 2011
  4. Junio C HamanoJan 22, 2011
  5. Ramkumar RamachandraJan 22, 2011
  6. 3/5 Build an svn-fi target in contrib/svn-feRamkumar Ramachandra, Jan 19, 2011
  7. 4/5 fast-export: Introduce --inline-blobsRamkumar Ramachandra, Jan 19, 2011
  8. Junio C HamanoJan 19, 2011
  9. Jonathan NiederJan 19, 2011
  10. Ramkumar RamachandraJan 20, 2011
  11. Jonathan NiederJan 20, 2011
  12. Ramkumar RamachandraJan 20, 2011
  13. Drew NorthupJan 20, 2011
  14. Ramkumar RamachandraJan 22, 2011
  15. Jonathan NiederJan 22, 2011
  16. Jonathan NiederJan 20, 2011
  17. Junio C HamanoJan 22, 2011
  18. 5/5 vcs-svn: Add dir_cache for svnloadRamkumar Ramachandra, Jan 19, 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.