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

is hosting a read-mostly git repo on a distributed file system practical?

From
Jon Seymour <jon.seymour@gmail.com>
Date
Apr 13, 2011, 01:40 UTC
Message-ID
<BANLkTiniGcRAHbt5LP2NVhE+c8grOr5sLA@mail.gmail.com>

Is it practical to host a read-mostly git repo on a WAN-based distributed file system?

The idea is that most developers would use the DFS-based repo to track the tip of the development stream, but only the integrator would publish updates to the DFS-based repo.

As such, the need to repack the DFS-based repo will be somewhat, but not completely, reduced.

Is this going to be practical, or are whole of repo operations eventually going to kill me because of latency and bandwidth issues associated with use of the DFS?

Are there things I can do with the git configuration (such as limiting repacking behaviour) that will help?

jon.
Next: Shawn Pearce
Message 1 of 3 in “is hosting a read-mostly git repo on a distributed file system practical?”
  1. Jon SeymourApr 13, 2011
  2. Shawn PearceApr 13, 2011
  3. Jon SeymourApr 13, 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.