Git LFS Quota issues

[MaulingMonkey]

I may have discovered why only master branch release builds were being built: git LFS quotas:

https://ci.appveyor.com/project/MaulingMonkey/visualrust/build/job/26a7xmxwanmx0snv

git clone -q --branch=master https://github.com/MaulingMonkey/VisualRust.git C:\projects\visualrust
Downloading build/7za.exe (1.03 MB)
Error downloading object: build/7za.exe (ff3706e): Smudge error: Error downloading build/7za.exe (ff3706e94d9b769f78e4271928382426cb034b11c5a0f6a8ffea35726cc03692): batch response: This repository is over its data quota. Purchase more data packs to restore access.

Apparently my fork counts against your quota. Sorry about that. build\ accounts for ~2MB, lib\ accounts for ~100MB in the form of two .7z files, apparently containing mingw installs. As a temporary measure I've disabled appveyor builds from my repository.

It looks like there may be ways to enable caching:

http://help.appveyor.com/discussions/problems/6274-git-lfs-and-build-cache

Some Options

• Bribe donate to whoever runs PistonDevelopers to get our quota increased
• Hack up appveyor's build scripts to cache lfs stuff (might not be sufficient)
• Switch to an external package manager (chocolatey? lpg likes vcpkg?)
• Just stop using git lfs and put things directly into the repository
• ???

What it's used for

MinGW

• build/7za.exe -- used to unpackage lib/*.7z
• lib/i686-7.1.0-release-posix-dwarf-rt_v5-rev0.7z 32-bit MinGW
• lib/x86_64-7.1.0-release-posix-seh-rt_v5-rev0.7z 64-bit MinGW
  We then repackage gdb and some dependencies from mingw directly into the .vsix as I understand it to enable some built in debugging: https://github.com/PistonDevelopers/VisualRust/blob/master/lib/mingw.msbuild . This could be axed in favor of:
• Windows Subsystem for Linux (Win 10+)
• https://chocolatey.org/packages/mingw/
  Alternatively, it might be worth seeing if it might be preferable to rely on one of the other existing integrations of gdb into visual studio instead of rolling our own...?

StrongNamer

• build/StrongNamer.0.0.5/Mono.Cecil.Mdb.dll
• build/StrongNamer.0.0.5/Mono.Cecil.Pdb.dll
• build/StrongNamer.0.0.5/Mono.Cecil.Rocks.dll
• build/StrongNamer.0.0.5/Mono.Cecil.dll
• build/StrongNamer.0.0.5/StrongNamer.dll
  I believe these allow us to use unsigned dependencies from signed assemblies. Might be worth seeing if we can get rid of the dependency by signing more of the projects. There are also nuget packages:
• https://www.nuget.org/packages/StrongNamer/
• https://www.nuget.org/packages/StrongNamer.For.MsBuild12/

[MaulingMonkey]

This should be resolved by now The quota should have refilled by now, although I'm keeping builds of my fork disabled for the moment.

[MaulingMonkey]

It looks like this remains a problem.

[Boddlnagg]

From the options that you have mentioned, I think that enabling caching and/or switching to an external package manager is the most sensible thing, although I don't know exactly for what kind of files LFS is being used for at the moment. Please don't put things directly into the repository ... LFS exists for a reason.

Ideally we could get rid of some large files completely (i.e., no longer depend on them at all) by cleaning up some stuff. I'm not sure if we really need all of this.

[MaulingMonkey]

Ran git lfs ls-files to get a full list.

[MaulingMonkey]

I'm thinking it may actually make sense for us to just remove MinGW from the package. While it's theoretically nice from a batteries included standpoint, but we don't include rustc (and for good reason IMO - you should be able to separately upgrade it via rustup etc.) - so why should we include racer (which may be tied to rustc versioning anyways, and can be installed/upgraded through cargo) or mingw (which has plenty of distribution channels of it's own that could be separately installed if you want gdb/gnu toolchain support)?

I'd want good messaging and instructions for if the user is missing components but I think it makes more sense to remove these outright than to worry about distribution mechanisms for them.

StrongNamer might remain a problem but it's a much smaller package...