Repository navigation
Binaries in the repo #739
Description
Activity
I hear you.
Is there any solid reason why this is as such? I'd really recommend a binary purge.
Actually, when we started to work on the
HistoryRewriterwith @ben, one of the end goal was to dogfood LibGit2Sharp in order to rewrite the history and reduce the size of the repository. At this time, the idea was to extract the binaries and host them externally. Each rewritten commit would contain a powershell script which would download the correct libgit2 binaries.Is there any solid reason why this is as such?
Yes, there is. Embedding the compiled binaries was a way to reduce the friction for contributors (at least on Windows).
The repo size already reached 100mb.
I'd be ok to shrink it down provided we find a way for contributors to not waste too much time updating to the correct version of libgit2 each time the submodule pointer has been bumped.
Externally hosting the binaries may turn into a burden in the long time run. So, the only option I can think of right now would be to provide a script that would force the init of the libgit2 submodule, and build the binaries on demand (a trimmed and tweaked version of
UpdateLibgit2ToSha.ps1). The drawback is that every contributor should have CMake installed on his/her computer to even run the tests.Another issue is the TeamCity CI server. In order to build libgit2, CMake would have to be installed on the agents (A counter-proposal could be to download the .zip version of CMake, extract it and use it to build libgit2).
Thoughts?
/cc @dahlbyk @kitbellew @ethomson @jamill @spraints @shiftkey @KindDragon
I don't believe 100MB is a huge repository size. Yes, binaries and Git do not play nice, but I think we're prematurely optimizing here.
The benefit we get by embedding the binaries are that it's super-easy to start contributing. While there definitely feels like some redundancy in the task of updating the submodule and committing the binaries, the fact that a contributor doesn't need to compile libgit2 to get started is a huge win.
And I'm fairly certain I've forgotten how to do that
I'm open to experimenting with incorporating CMake into the build script, but at this stage I'd favour fewer moving pieces in the build process over reducing the repository size.
- I usually don't put big files under version control but in this case it didn't look like a problem
- why it was nice not having to build myself:
- the first time I tried building
libgit2, I ran into thecdeclvsstdcallissue (and it took me some time to figure out that it wasn't some other problem); - when I ran the PowerShell script yesterday, it kept trying to load old visual studio which wasn't installed anymore
- the first time I tried building
- if others prefer to store binaries outside, there are other ways:
- naturally, nuget contains the released versions, although to release a new one is a chicken and egg problem
- cursory search for github and binaries returns:
https://github.com/proxy/help.github.com/articles/distributing-large-binaries
The benefit we get by embedding the binaries are that it's super-easy to start contributing.
This.
So. Maybe this is a stupid question, but what about nuget?
I made a native nuget package for libgit2 just now, which was quite straightforward. Note that native nuget packages only create a native target. It seems from https://nuget.codeplex.com/discussions/396720 like we might be able to extend this to apply to managed targets as well.
Would this be a reasonable solution?
Hi all, to summarize what I sent to @nulltoken, CodeBetterCI can support you if you choose to go the cMake route, but like a lot of you, I personally also think that nuget is the way to go - I think a required C compile is a big barrier to C# devs who may not even have C tools downloaded or have any familiarity with them.
Oh, and while we're at it. Can we ship a nuget executable in .nuget and add our dependencies from Lib from NuGet? (1 executable vs X libs)
Yeah, we could include them as nuget packages and add a nuget restore in the solution if we include a NuGet Binary.
Ok. Let's try this. Just a question though. Why the
Exists('$(SolutionDir)\..\.git')"condition?Ah. It was a hackfix for MD to not do it from tarballs.
As we now rely on a NuGet package for binaries, do we still need to keep this opened?
None at all.
This is a major issue. The repo size already reached 100mb. This is insane and not a good course of action.
Is there any solid reason why this is as such? I'd really recommend a binary purge.