On 09/11/2016 01:54 PM, Stephan Beal wrote: > On Sep 11, 2016 18:18, "Adam Jensen" <han...@riseup.net > <mailto:han...@riseup.net>> wrote: [snip] >> ''' >> 5.4 Unversioned File Sync >> >> "Unversioned files" are files held in the repository where only the most >> recent version of the file is kept rather than the entire change >> history. Unversioned files are intended to be used to store ephemeral >> content, such as compiled binaries of the most recent release. >> ''' >> >> The phrase "ephemeral content" is a bit disconcerting. It suggests >> values and attitudes towards this data which will probably be reflected >> in the requirements, specification, and implementation of the software. >> >> In the use-case I have in mind, this data would be "immutable content" >> and should be considered precious. > > That's not, as i understand it, the intention of unversioned filed. > Anything "important" needs to be checked in (versioned). Unversioned > files are primarily intended for hosting pre-built binaries and such.
We might not be intersecting on this point; a perspective difference, I suspect. What I am suggesting is that the current intention of unversioned files might need be slightly tweaked to encourage an additional use-case where the repository supports the organization and management of critical data (immutable; a snap-shot of reality; large binary files) in addition to highly revised text files such as data analysis scripts, annotations, and documentation. Use of the unversioned files facility for storage and management of fleeting, intermediate files is also valuable. Quoting Chancellor Palpatine, I suggest we "embrace...a larger view" of unversioned files. On the other hand, it is still unclear [to me] if Fossil can be used this way. Once more complete unversioned files functionality is available, I can answer some of my questions through tests of the system. The critical points of interest are: 1. Maximum single unversioned file size. 2. Repository performance and integrity as overall size increases. 3. FuseFS performance. 4. Sync performance/reliability/usability. Once I have a better idea of these various characteristics and constraints, then it should be possible to estimate where Fossil might be a reasonable solution and where some other approach is needed. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
