On 09/11/2016 04:42 PM, Scott Robison wrote: > I may not be understanding you, but from my point of view, it already > does what you want by supporting versioned files that you simply never > change. For example, you could have a repo that has a structure along > the lines of: > > /root/static-data/ -> a place to store lots of big binary blobs that you > don't intent to ever modify. > > /root/dynamic-data/ -> a place to store things that you want to track > the history for > > Is this inadequate? If so, how or why?
My impression is that with a different class of files, the operations, interface, and underlying implementation can be specialized for the qualities, characteristics, and various needs that are peculiar to that class. For example, an unversioned file might avoid some of the CPU, memory, and/or storage requirements that are involved in versioned files. Also, I imagine there might be some specialized commands and alerts associated with the two major use-cases for unversioned files (critical immutable data, and temporary intermediate data). Ultimately, I suppose the purpose of a tool like Fossil is to assist in the management of complexity. Differentiation and specialization seems like a fundamental part of that. But yeah, my tests all currently make use of the versioned file class for storage. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
