3 ms·

Having helped several large companies migrate I would agree that this is a top concern, but it can be shown that Git can handle all of the users without any pro

by icefox 14y ago

Having helped several large companies migrate I would agree that this is a top concern, but it can be shown that Git can handle all of the users without any problem. Common tips like: If you are using pure ssh beyond 500 users you want to move away from the stock sshd. When possible setting up git to handle fetches over smart-http can scale git significantly (I would use all available bandwidth to the box before the cpu was anywhere near to pegged). The usual server side backups, routing and distributing load to local offices are all issues that are not too difficult to deal with. Even going through a worse case situation and on purpose corrupting the git database as an exercise is worth doing with new admin's. Inside the enterprise firewall there are a number of tools such as gitolite, github enterprise, gerrit, etc out there that are available to make the users and server admin's happy. Beyond that there are presentations, books, youtube videos, wiki's etc. I found making sure there is one "local export" really helps make things go smoother and and internal chat room / mailing list for Git can't hurt too. Slowly migrating users by teachings the early adopters with git-p4 also helps to prevent the sudden switch on "Monday" that goes horribly wrong causing everyone to loose a few days. The real problem has been shops that have 400GB perforce servers and they employed absolutely no rules about where things would live on the server. This would result in Perforce clients that would cherry pick directories from all sorts of random sub directories across the Perforce server to build a product (v.s. say something simpler like projectFoo/, 3rdparty/, and binaryTools/) The worst are the exceptions in the perforce client such as the perforce client would grab the src/ directory, but exclude src/vs/ because a few years ago someone checked in a visual studio install into the src directory and somewhere someone is still using it so they can't remove/move it... Even if they stick with Perforce companies like this really should clean up their repositories, call it simple professionalism. After a repository is cleaned up (even a basic pass can make a huge deal) then using git on top of perforce or even thinking of migrating is much easier to do. Using Git inside large companies is completely doable right now. In the past when Git was younger I gave a few presentations in the Boston area (where I live) to companies that were interested in learning more. If your in the area and if you just want to pick my brain on the topic or how it might apply to your situation I am always up for grabbing lunch.

to3m 14y ago
What do you do about storing binary files in git? And is git not actually bothered by having a 400GB repository? I was under the impression that sort of thing was just not its intended use.
- icefox 14y ago
  At least one big company that was using Perforce to store tons (TB's+) of binary assets that was looking to migrate to Git after talking it over with them I ended up recommended they stick with Perforce. For users that are just looking for a place to store files and not looking to take advantage of features of a distributed revision control system Git isn't the best solution. A good example is a special effects company where you have a massive amount of assets (PB?) including storing multiple copies of each frame in full resolution raw for the movie. If it you only wanted HEAD local hard drives can't even hold all that data and you only want to work with small parts at a time. For this situation stock Git is absolutely not what you want. Before anyone tries to sell you that "of course Git scales" you really need to find out more information. Git does have large file support via extra tools that solve it in a handful of different ways, (sidenote one tool: bup is a very very cool from a technical perspective). With large repositories you must also find out are you dealing with a lot of small files or a handful or large files. Windows for example will fall on its face if you try to dump it with a ton of files which git will stat (say just a 4GB git repo) when you run git status while linux can't handle it with no problem. Once you get beyond 4GB in repository size you need to evaluate the problem more closely. Nine times out of ten it has been as simply as splitting the repo into two, one that contains the source and is 1GB and leaving the 399GB of binaries (for 6 platforms, debug and release, etc etc) in a better long term archive storage system be that another git repo using one of the above tools, perforce, or most likely some server that IT manages. An easy way to look at the 400GB repo is today I doubt you are syncing all 400GB to your laptop from perforce (Stock macbook air's max out at only 256GB for example) so how is your perforce client setup? What data does it grab? which data does it leave on the server?
  - to3m 14y ago
    The point about using separate storage is reasonable. Leaving aside the issue of locking binary files, having to potentially use multiple systems or repositories is partly my stumbling block when it comes to any serious replacement to perforce. There are real benefits to having just one system, and having absolutely everything in just one place. One set of revision numbers, one client program. And, most importantly, no need to think about what to do if you have something you want to keep (aside from putting it in an appropriate folder, as you rightly point out). If you want to keep it, it goes in perforce. Doesn't matter what it is, or how much of it there is, perforce will take it. And that's that. I've seen the annoyances of using multiple depots/databases/repos/etc. with Alien Brain in the past, and that was just one system. Now I'm working on a smaller project that uses both git and SVN, and even though it's a smaller project, it's still annoying today. Being able to have just one system, that can swallow absolutely everything without a fuss (while not being especially annoying to use, like Alien Brain was), is a big advantage.

by icefox 14y ago

to3m 14y ago

What do you do about storing binary files in git? And is git not actually bothered by having a 400GB repository? I was under the impression that sort of thing was just not its intended use.

icefox 14y ago
At least one big company that was using Perforce to store tons (TB's+) of binary assets that was looking to migrate to Git after talking it over with them I ended up recommended they stick with Perforce. For users that are just looking for a place to store files and not looking to take advantage of features of a distributed revision control system Git isn't the best solution. A good example is a special effects company where you have a massive amount of assets (PB?) including storing multiple copies of each frame in full resolution raw for the movie. If it you only wanted HEAD local hard drives can't even hold all that data and you only want to work with small parts at a time. For this situation stock Git is absolutely not what you want. Before anyone tries to sell you that "of course Git scales" you really need to find out more information. Git does have large file support via extra tools that solve it in a handful of different ways, (sidenote one tool: bup is a very very cool from a technical perspective). With large repositories you must also find out are you dealing with a lot of small files or a handful or large files. Windows for example will fall on its face if you try to dump it with a ton of files which git will stat (say just a 4GB git repo) when you run git status while linux can't handle it with no problem. Once you get beyond 4GB in repository size you need to evaluate the problem more closely. Nine times out of ten it has been as simply as splitting the repo into two, one that contains the source and is 1GB and leaving the 399GB of binaries (for 6 platforms, debug and release, etc etc) in a better long term archive storage system be that another git repo using one of the above tools, perforce, or most likely some server that IT manages. An easy way to look at the 400GB repo is today I doubt you are syncing all 400GB to your laptop from perforce (Stock macbook air's max out at only 256GB for example) so how is your perforce client setup? What data does it grab? which data does it leave on the server?
- to3m 14y ago
  The point about using separate storage is reasonable. Leaving aside the issue of locking binary files, having to potentially use multiple systems or repositories is partly my stumbling block when it comes to any serious replacement to perforce. There are real benefits to having just one system, and having absolutely everything in just one place. One set of revision numbers, one client program. And, most importantly, no need to think about what to do if you have something you want to keep (aside from putting it in an appropriate folder, as you rightly point out). If you want to keep it, it goes in perforce. Doesn't matter what it is, or how much of it there is, perforce will take it. And that's that. I've seen the annoyances of using multiple depots/databases/repos/etc. with Alien Brain in the past, and that was just one system. Now I'm working on a smaller project that uses both git and SVN, and even though it's a smaller project, it's still annoying today. Being able to have just one system, that can swallow absolutely everything without a fuss (while not being especially annoying to use, like Alien Brain was), is a big advantage.