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

Re: [PATCH 0/14] resumable network bundles

From
Tay Ray Chuan <rctay89@gmail.com>
Date
Nov 12, 2011, 16:11 UTC
Message-ID
<CALUzUxqsLP11Tcsoc1tzGMfNcMqor2wQF+Yutu3FRiTin4Pnew@mail.gmail.com>
In-Reply-To
<20111110074330.GA27925@sigill.intra.peff.net>
On Thu, Nov 10, 2011 at 3:43 PM, Jeff King <peff@peff.net> wrote:
Show 16 quoted lines
> One possible option for resumable clones that has been discussed is
> letting the server point the client by http to a static bundle
> containing most of history, followed by a fetch from the actual git repo
> (which should be much cheaper now that we have all of the bundled
> history).  This series implements "step 0" of this plan: just letting
> bundles be fetched across the network in the first place.
>
> Shawn raised some issues about using bundles for this (as opposed to
> accessing the packfiles themselves); specifically, this raises the I/O
> footprint of a repository that has to serve both the bundled version of
> the pack and the regular packfile.
>
> So it may be that we don't follow this plan all the way through.
> However, even if we don't, fetching bundles over http is still a useful
> thing to be able to do. Which makes this first step worth doing either
> way.

Jeff, this is a great series, I think the cleanups and refactors should get integrated independently of the bundle-cloning stuff.

One thing I'm not comfortable with is the "flexibility" allowed in bundle fetching - servers are allowed to send bundles if they see fit, and we have to detect it when they do (if I'm reading the "surprised" scenario in patch 9 correctly).

Perhaps we can expose bundle fetching through /objects/info/bundles? It could possibly contain information about what bundles are available and what revs they contain. If bundles are found, fetch them; otherwise, go through the usual ref advertisement and other steps of the pack protocol.

That way, we take out the "surprise" factor in the fetching protocol.
-- 
Cheers,
Ray Chuan
Previous: David Michael BarrNext: Jeff King
Message 22 of 23 in “resumable network bundles”
  1. 0/14 resumable network bundlesJeff King, Nov 10, 2011
  2. Jeff KingNov 10, 2011
  3. 01/14 t/lib-httpd: check for NO_CURLJeff King, Nov 10, 2011
  4. 02/14 http: turn off curl signalsJeff King, Nov 10, 2011
  5. Daniel StenbergNov 10, 2011
  6. Jeff KingNov 11, 2011
  7. 03/14 http: refactor http_request functionJeff King, Nov 10, 2011
  8. 04/14 http: add a public function for arbitrary-callback requestJeff King, Nov 10, 2011
  9. 05/14 remote-curl: use http callback for requesting refsJeff King, Nov 10, 2011
  10. 06/14 transport: factor out bundle to ref list conversionJeff King, Nov 10, 2011
  11. 07/14 bundle: add is_bundle_buf helperJeff King, Nov 10, 2011
  12. 08/14 remote-curl: free "discovery" objectJeff King, Nov 10, 2011
  13. 09/14 remote-curl: auto-detect bundles when fetching refsJeff King, Nov 10, 2011
  14. 10/14 remote-curl: try base $URL after $URL/info/refsJeff King, Nov 10, 2011
  15. 11/14 progress: allow pure-throughput progress metersJeff King, Nov 10, 2011
  16. 12/14 remote-curl: show progress for bundle downloadsJeff King, Nov 10, 2011
  17. 13/14 remote-curl: resume interrupted bundle transfersJeff King, Nov 10, 2011
  18. 14/14 clone: give advice on how to resume a failed cloneJeff King, Nov 10, 2011
  19. Junio C HamanoNov 10, 2011
  20. Jeff KingNov 11, 2011
  21. David Michael BarrNov 11, 2011
  22. Tay Ray ChuanNov 12, 2011
  23. Jeff KingNov 12, 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.