This would be a great help. Whether SF or bitbucket or Dropbox or Google Drive or basically anywhere safe, I think this is a fine idea. Not sure about one gigantic gz though, it would complicate the software release process a bit (download the old gz, add new docs to it, re-zip, and re-upload). If they could be stored essentially unpacked that would be perfect.
Current release process and checklist is at http://www.scons.org/wiki/ReleaseHOWTO#Simplified_2012.2B-_Mercurial-based_Release_Procedure_.28EXPERIMENTAL.29 - it's not really experimental anymore, 2.2 and 2.3 both used it and it was pretty smooth. On Sat, Jul 20, 2013 at 8:56 AM, anatoly techtonik <[email protected]>wrote: > On Sat, Jul 20, 2013 at 2:27 PM, Antonio Cavallo > <[email protected]>wrote: > >> Nope, using a version control on binary files is not wrong: in the gaming >> industry these are called "assets" and studios do this all the time. >> > > I believe that even in this case compiled assets are stored in a > repository separated from the main source code tree. > > >> You could put the docs into a gigantic gz file and extract as part of the >> doc building process on the fly: that's what I do with doc (mine is +250Mb >> thanks to MathAjax). > > > I thought about the same - upload this gigantic .gz to SF. > -- > anatoly t. > > _______________________________________________ > Scons-dev mailing list > [email protected] > http://two.pairlist.net/mailman/listinfo/scons-dev > > -- Gary
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
