On Sun, Sep 11, 2016 at 1:49 PM, Adam Jensen <han...@riseup.net> wrote:
> 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. > 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? -- Scott Robison
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
