That would be great. I could then add your repo as a submodule, and someone would just need to pull both for updates. I assume that it would be pretty easy for you to reset the commits, since only new versions will be added and there would be nothing in the commit history you would need to preserve.

Alternatively, if the commits themselves cannot be removed easily, a new repo could be created for each version. Then, the submodules reference can just be updated instead of updating the submodule itself.

We could also use releases on the tor-download-web repo, and then have a script download the files for each release automatically. The script can be updated through git to take care of updating the files.

Which solution seems best?


On Sun, May 4, 2014 at 6:00 PM, Griffin Boyce <griffin@cryptolab.net> wrote:
William Papper wrote:
If we can go up to 1.7GB, then that's not a problem. There could also
be a simple script setup to clone tbb-bin [6] if GitHub does start to

enforce the limit on our repo, or we could start looking at external
sources. My ideal is that someone can just use "git clone" and have a
working mirror, so I'd prefer for the script to be a backup plan.

Is tbb-bin currently updated by a script, or is everything done
manually?

  Everything is done manually.  If this gets used as the source for mirror downloads, I'd likely remove the version numbers (with a mention in the readme) so that out-of-date pages will continue to link to working bundles.  And right now I blow away the repo entirely instead of updating it, but I can just set up a different process to redact the old bundle commits and add new ones.  (Rather than have git store all the outdated bundles, which could get problematic when cloning).

~Griffin

________________________________________________________________________
Tor Website Team coordination mailing-list

To unsubscribe or change other options, please visit:
https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team