5 ms·
Deploying a major release as a diff to a complex development environment is far from effortless. They probably figured the effort vs. payoff ratio didn't work o
by mustpax 16y ago
Deploying a major release as a diff to a complex development environment is far from effortless. They probably figured the effort vs. payoff ratio didn't work out, compared to making improvements to the product itself.
- someone_here 16y agoIt's strange to me how products like source control manage this. Why is this different?
- Groxx 16y agoThey manage it for typically-small changes. Try computing a patch for the differences between major revisions of a Linux project, and watch how long it takes. Then try to apply it.
- malkia 16y agoWith Visual Studio for example, it's not only about merging files, but installing various DLLs (for the runtime - vcredist*.exe), COM objects, .NET stuff, etc. Also creating (if possible) proper uninstalls. VS2008 runs some SQLserver, PDBserver, and who knows what else (run ProcExp and see)
- Tamerlin 16y agoSource control applications don't generally worry about dependencies, and they also generally aren't concerned with multiple projects. Using .NET as an example, the SDK patches would include: Drivers DirectX XNA WPF BackOffice SQL Server (or Express or Lite or whatever they call it) System libraries ASP.NET C# F# ILR C++ .NET VB.NET And the list goes on. Apple's developer kit has a similarly vast suite of libraries and services, I just don't know all of their names. Each one in isolation wouldn't be all that big a deal, but combine them and you have the option of massive downloads or a nightmarish dependency management problem.
- Glide 16y agoI remember having to upgrade VS 2005 to VS 2005 SP1. It took 2 hours to apply the changes. And it was difficult to tell if the updating application froze or was still working. So while patching is nice, it is a huge effort to get it done cleanly.