Hello, a few days ago I ran across this: http://www.kickstarter.com/projects/joeyh/git-annex-assistant-like-dropbox-b... and made a symbolic contribution. However, this project could become one of the convenient options to distribute ConTeXt, in the sense that it would probably allow sparse checkouts from git, and we could have one huge git repository and with some basic scripting on the client side (in the same way as it is done now with rsync), user could choose to download just MKIV or just the basic fonts in contrast to a huge collection of fonts that might end up in that big repository. Basically, git could replace rsync (the rsync way could stay; this would just add an extra option). At least that is my understanding, but I admit that I don't have the full picture in front of my eyes and I would actually be grateful for the second opinion from other ([not necessarily] git) experts here. The reason why I'm writing is that by donating the following amounts, one might be able to ask for additional features if/when needed: 100 $ Help set my priorities for which features are the most important. I aim to make the git-annex assistant please you right out of the box by supporting exactly what you need. 250 $ Be my beta tester for the git-annex assistant. You will influence the project throughout, and will set my priorities for which features are the most important. and if this really becomes an important way to distribute ConTeXt, we could either make some kind of "group" donation of a few volunteers, or consider using part of ConTeXt Group funds (as ConTeXt Group was established exactly for the reason to fund projects that are important to the community). If that can help ConTeXt users switch to older version more easily, the requested amounts for funding are more than reasonable. This is what the author has answered to one of my question about how I could let user select which modules to install (module = a collection of fonts, a collection of mkii-only related files, engine-related files etc.) out of the whole distribution:
I can think of a few ways to handle the checkout of a specific set of modules with git-annex. If there's a text file manifest listing the files in each module, then something like: git annex get $(cat 1.manifest 3.manifest 7.manifest ...) Better, put each module into its own git branch. Then the user can merge in the branches for modules they want. This has the advantage that the only files they'll have visible in their git repository will be for the selected modules. git merge module/1 module/3 module/7; git annex get Users would want to do that after every git pull, presumably, so probably a shell script would be called for.
What I didn't ask is whether Mac or other non-linux systems would also be supported. Windows seems to be feasible, but not is not guaranteed to happen: "If I'm funded for a year ($20k), I will spend at least one month of it in Windows purgatory, making the port happen. No guarantees of success on this one!" (he is missing less that $1k for that goal though). ----------------------------------- Actually, my original idea/suggestion was actually slightly different and would probably not need any additional software to be installed, but would not necessary be in scope of this project. I'm still looking for a way to have a "smarter" rsync server, so that I could use something like rsync -av rsync://contextgarden.net/suite/context/@tag:2013.12.13T12:13 texmf-context/ and rsync would then serve files from a particular branch/tag/sha of a git repository, without the need to have different version of The biggest problem with everything is that I'm somehow narrow-sided. I need someone to help me think a bit out of the box and get a broader picture. To help me decide if one of the above options (patching rsync server or being beta testers for git-annex) would make sense. Of course anyone is invited to make his/her own donation to git-annex independent of whether or not it will make sense for us to use it, but if there is a consensus that it would be worth using it for the distribution, we could combine our donations or make a donation from ConTeXt Group to become the official beta testers. Mojca (PS: It is not ready yet and I've been promising it for way too long already, but the first change that I will do to the distribution will be the ability to use both current approach as well as a git repository (without the option to exclude stuff), so that if something breaks in the middle of a project after ConTeXt update, it will be trivial to go back in time to any given version of ConTeXt & matching LuaTeX & fonts. At the moment going back in time requires at least a bit of creativity, for example fetching the latest working version of ConTeXt from existing unofficial Git repository etc.)