We did migrate from Perforce to Git for a fairly large repositories, and I can relate to some of the issues. Luckily we did not had to invent VFS, although git-lfs was useful for large files.
Microsoft Office migration from Source Depot to Git
21–30 of 290 posts
Re: Microsoft Office migration from Source Depot to Git
#22[flagged]
This isn’t Reddit. It’s a lame drive-by joke. The system is working.
Re: Microsoft Office migration from Source Depot to Git
#23Re: Microsoft Office migration from Source Depot to Git
#24> Authenticity mattered more than production value.
Thanks for sharing this authentic story! As an ex-MSFT in a relatively small product line that only started switching to Git from SourceDepot in 2015, right before I left, I can truly empathize with how incredible a job you guys have done!
Re: Microsoft Office migration from Source Depot to Git
#25I actually remember using Perforce back in like 2010 or something. And I can't remember why or for which client or employer. I just remember it was stupid.
And expensive.
Re: Microsoft Office migration from Source Depot to Git
#26I actually remember using Perforce back in like 2010 or something. And I can't remember why or for which client or employer. I just remember it was stupid.
There's still a lot of Perforce around. I've thankfully managed to avoid it but I have plenty of friends in the industry who still have to use it.
Re: Microsoft Office migration from Source Depot to Git
#27In about 2010, I briefly had a contract with a security firm with one dev, and there was no source control, and everything written was in low quality PHP. I quit after a week.
What kind of security services did they provide? Breaches?
Re: Microsoft Office migration from Source Depot to Git
#28I actually remember using Perforce back in like 2010 or something. And I can't remember why or for which client or employer. I just remember it was stupid.
Perforce is convoluted and confusing, but I don't think it's really fair to call it stupid. It is still virtually unmatched in a couple of areas.
Re: Microsoft Office migration from Source Depot to Git
#29[flagged]
> Microsoft had to collaborate with GitHub to invent the Virtual File System for Git (VFS for Git) just to make this migration possible. Without VFS, a fresh clone of the Office repository (a shallow git clone would take 200 GB of disk space) would take days and consume hundreds of gigabytes.
It takes less than an hour on my third world apartment wifi to download Call of Duty Modern Warfare remake which is over 200 gygabytes. Since we're not talking about remote work here, I think Microsoft offices and servers (probably on local network) might have managed similar bandwidth back then.
Re: Microsoft Office migration from Source Depot to Git
#30Its oddly fascinating that Microsoft has managed to survive for so long with ancient/bad tools for software engineering. Almost like “life finds a way” but for software dev. From the outside it seems like they are doing better now after embracing OSS/generic dev tools.
At one point source depot was Toincredibly advanced, and there are still features that it had that git doesn't. Directory mapping being a stand out feature! Being able to only pull down certain directories from a depot and also remap where they are locally, and even have the same file be in multiple places. Makes sharing dependencies across multiple projects really easy, and a lot of complicated tooling around "monor…
As always, git's answer to the problem is "stop being afraid of `git submodule`."
Cross-repo commits are not a problem as long as you understand "it only counts as truly committed if the child repo's commit is referenced from the parent repo".