On Sun, Sep 11, 2016 at 3:27 PM, Adam Jensen <han...@riseup.net> wrote:
> 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). > You are generally correct that a specialized solution can often improve on the generalized solution by some metric. There are ways to do things with huge files (such as diff them) that wouldn't strictly require as much memory as the general case does, but the utility is marginal at best for fossil's design case. Very few people would have a need to compute deltas for a terabyte sized file, so it is not implemented. Not that you were suggesting someone should be able to do that, I was just going for the first very ridiculous idea that came to mind. In any case, it might be possible to make the unversioned functionality "better" in some way, but it seems like a less than ideal use of time IMO. Fossil already handles the critical file tracking for versioned files, just don't overwrite them. And if at some point you discover that the critical data really is wrong or outdated, you can commit a new version over the old one. In essence, the unversioned critical data functionality you've envisioned works off the assumption that you can see into the future and guarantee you'll never change your mind about the utility of versioning for these files. YMMV As SB said, it's just an opinion, and not one that drives the project. I just wanted to try to understand what you were hoping to gain from it, so thanks for answering my questions. > > 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. Of course, adding differentiation and specialization increases complexity, so it can be a tricky balancing act. -- Scott Robison
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
