On Aug 11, 2017, at 2:55 PM, Damien Sykes-Lindley <dam...@dcpendleton.plus.com> wrote: > > so that sounds can easily be edited and changed without loss of quality they > are uncompressed PCM data. I suppose I could convert them to FLAC
I must not have been clear: when you cannot use a text-based file format with Fossil, you at least want to use an *uncompressed* binary file format. So, stick with PCM, WAV, AIFF, etc. Absolutely do not switch to FLAC. If you move to a game engine that wants a compressed audio format — some use Ogg Vorbis, for example — my recommendation is that you still store the data in Fossil in uncompressed form, but add some build rule that converts it to the compressed form for testing and delivery. Not only will this make Fossil — or really, *any* VCS — happier, it lets you change your compression settings, format, etc. without bloating the repository with multiple versions. I speak from experience. My largest repository has essentially the same graphics for a web app in: 1. 8-bit GIF format from the days before PNG was in all browsers 2. 8-bit PNG format from the days before IE got the ability to cope with alpha channels in PNG 3. A different set of 8-bit PNGs when we changed our UI color scheme enough that the old 8-bit matting caused color fringing when the old PNGs were composited atop the new app background. 4. 24-bit PNG format once we finally dropped support for those old versions of IE If I’d had the foresight to write a script to convert them from the high-res PSD or SVG forms to GIFs or PNGs, I’d still only have one version of most of these graphics. > As for the executable, sometimes that gets included due to the fact that we > forget to delete it after testing an executable copy and don't use Fossil's > ignore feature You can “shun” those after the fact to strip them out of the repo. You have to get all clones to cooperate for this to work, but it’s doable. > compiled language like C++ where there are many assets to manage can make > compilation a real ballache - maybe that's because I'm so new to such > languages. If your build system is not reliable, I’d say that’s where you should spend your efforts, not on trying to get Fossil to cope with checkins containing unstripped binaries generated from other files that are efficiently stored in the repository. You probably need some amount of scripting that lets you clone a repository and then run the script to get things into a buildable shape, automatically and reliably. Anything less becomes the PITA you’ve run into. Windows is a bit of an outlier here: on all the other major platforms, we have powerful, scriptable build systems, which we had to build in order to deal with the complexity of platform differences. A positive side effect of that is that we can script our way out of most build complexities. I pity the Windows dev that is forced to choose between batch files and PowerShell to achieve the same end. > I had no idea about the checksum setting. Despite three year usage, it seems > I've only scratched the surface of Fossil. Again, another reason why I put > some of my thoughts out there. Some users, and of course the developers > themselves, who are much more knowledgeable on these things than I am. We now await a repeat of your tests. :) _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
