I'm evaluating the feasibility of moving my team from SVN to git. We have a
very large repo. [1] We will have a central repo using GitLab (or similar)
that everybody works with. Forks, code sharing, pull requests etc. will be
done through this central server.
By 'performance', I guess I mean *speed *of day to day operations for devs.
- (Obviously, trivially, a (non-local) clone will be slow with a large
repo.)
- Will a few simultaneous clones from the central server also slow down
other concurrent operations for other users?
- Will 'git pull' be slow?
- 'git push'?
- 'git commit'? (It is listed as slow in reference [3].)
- 'git stautus'? (Slow again in reference 3 though I don't see it.)
- Some operations might not seem to be day-to-day but if they are called
frequently by the web front-end to GitLab/Stash/GitHub etc then they can
become bottlenecks. (e.g. 'git branch --contains' seems terribly adversely
affected by large numbers of branches.)
- Others?
Assuming I can put lots of resources into a central server with lots of
CPU, RAM, fast SSD, fast networking, what aspects of the repo are most
likely to affect devs' experience?
- Number of commits
- Sheer size of repo
- Number of tags.
- Number of branches.
- Binary objects in the repo that cause it to bloat in size (1)
- Other factors?
-
- Of the various HW items listed above --CPU speed, number of cores,
RAM, SSD, networking-- which is most critical here?
- (Stash recommends 1.5 x repo_size x number of concurrent clones of
available RAM. I assume that is good advice in general.)
Assume ridiculous numbers. Let me exaggerate: say 1 million commits, 15 GB
repo, 50k tags, 1,000 branches. (Due to historical code fixups, another
5,000 "fix-up branches" which are just one little dangling commit required
to change the code a little bit between a changeset a tag that was not
quite made from it.)
While there's lots of information online, much of it is old [3] and with
git constantly evolving I don't know how valid it still is. Then there's
anecdotal evidence that is of questionable value.[2]
Are many/all of the issues Facebook identified [3] resolved? (Yes, I
understand Facebook went with Mercurial. But I imagine the git team
nevertheless took their analysis to heart.)
Steve
[1] (Yes, I'm investigating ways to make our repo not so large etc. That's
beyond the scope of the discussion I'd like to have with this question.
Thanks.)
[2] The large amounts of anecdotal evidence relate to the "why don't you
try it yourself?" response to my question. I will I I have to but setting
up a properly methodical study is time consuming and difficult --I don't
want to produce poor anecdotal numbers that don't really hold up-- and if
somebody's already done the work, then I should leverage it.
[3] http://thread.gmane.org/gmane.comp.version-control.git/189776
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
