-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upstream changed #3
Comments
Hmm, I hoped they'd keep the split repo. So far the options I see are:
|
Including 2.2GiB is not an option to me. I assume it would also be a huge issue for people trying to get into nxdk development, if they have to clone the repo for a very long time (and waste so much memory). It was only an option, if we decentralized nxdk, and made binary releases (so only people who want to work on libcxx would have to clone it).
Yes, I also considered this. This is also really bad, because we will have different hashes for the revisions. So we'll manually have keep track of upstream revisions (github won't offer auto-comparisons for example). Rebasing might become an issue, because we need stability for the underlying revisions. There's also I guess another option is to only do very shallow clones. - but even at |
I really don't see this as a large issue.
Sorry to hear this, really. Can I offer gifting you a 16GB USB drive? You can get them readily for essentially pennies. |
I would heavily disagree. We don't offer an app like Visual Studio - why would our source be as big as that? Additionally that comparison is not really useful at all. I would vote for the |
This sounds interesting https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/; especially when considering https://stackoverflow.com/questions/6238590/set-git-submodule-to-shallow-clone-sparse-checkout. So it might be possible to have the full monorepo online, but we could checkout the individual submodule directory. |
Hm, this would save some space for the checkout, but it appears that it still has to clone the full repo - this can be fixed with the sparse cloning options, but that comes with the usual drawbacks of requiring extra steps if you want to be able to actually work on the code in the submodule. |
Yes, but at least you get to do some smaller changes. Just don't attempt to bring an IDE, do a full blame or similar (personally, I do most of that on the GitHub web-ui anyway). I'll have to do some more testing, my favorite so far is this:
It is about ~200MiB when initialized, but contains the entire commit history for libcxx. Problems only arise when you do
Another way to prevent exploding the repo size could be to also clone shallow-since by date or a fixed depth (a couple thousand commits should be good enough). I don't think there's a clone shallow-since by commit for some reason? For users, we can do this, which is ~50MiB, but obviously shallow:
In size, this is comparable to a However, regardless of what you prefer, all of the above is inherently incompatible with submodules. Currently, we use .gitmodules in nxdk, but it's not possible to force sparse checkout or filters for the submodule. We could only do a shallow clone from .gitmodules, but that's already large and would mean extra steps for setting up a tree for development. I think it's still worth considering to migrate to the monorepo. Personally I'd like to slim down nxdk anyway. If we have a simple shell script to initialize / install the packages, that's probably fine. We could have different settings for setting up a user and development tree. As a user, I'd just shallow clone and partial clone for using nxdk anyway - heck, I'd probably even delete the git repositories after building binary libs. I'd only clone those repositories if I need to do actual changes to them. So the potential options I see are:
I think all of those options suck. However, I think migrating to the mono-repo is the best option though:
|
Is there consensus on migrating to the mono repo? |
https://github.com/llvm-mirror/libcxx is no longer being updated. Instead, https://github.com/llvm/llvm-project should be used.
Unfortunately, this new repository is not just libcxx, but all of LLVM, so the repository is probably very large now.
I'm not sure how to address this, while also keeping it maintainable and without requiring users to download a bunch of stuff they won't need.
The text was updated successfully, but these errors were encountered: