On 9/12/2016 5:59 AM, Ron W wrote:
On Sun, Sep 11, 2016 at 12:18 PM, Adam Jensen <han...@riseup.net
<mailto:han...@riseup.net>> wrote:
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. The goals would be to avoid
accidental loss and/or corruption. It isn't a low-value, fleeting
scratch-pad that would be thrown away on a regular basis.
Unversioned means that if the file is committed again, the new contents
will replace the current contents.
If you only ever commit the (unversioned) file once, then it's contents
will remain.
In current fossil, the way to create a permanent and immutable file is
to check it in. It can be thereafter (immutably) recovered by knowing
its name and version, which can be summarized by its SHA1 hash. Syncing
to multiple copies of the repository and taking backups improves the
security of the data, but nothing can modify an artifact after it is
checked in.
I suppose, what you are looking for is a mechanism for preventing
further commits to those files, therefore preventing the contents from
being replaced.
Perhaps marking the file as a "closed leaf" could be used as a means to
achieve this immutability you are seeking.
That would prevent further work on a branch containing that file, but
only if that branch were the only branch holding the file. But then it
would only be visible in the file system in a checkout of that specific
branch. That would put a sizable crimp on the utility of such a file.
That said, using a closed branch as a parking place for the data could
work if combined with a build script that used "fossil artifact" to
extract the immutable data files.
If the data did need to mutate, you would reopen the branch and checkin
the change. Then back on the the development branch you would edit that
build script to request the new artifact ID.
Clumsy, perhaps, but it would work today.
There might be some value to being able to mark a file as "locked"
somehow. Problem is that tags only relate to manifests, not to the
individual files inside. I think it would require an extension to the
manifest format (and the table schema too) to support such a per-file lock.
But for some kinds of files, having a stumbling block that prevents
casual changes might have sufficient value to be worth implementing in
fossil itself. Without per-file tagging, you could have a build script
that verifies the "immutable" files have not mutated, and then require
that script be edited if a reason to update the immutable data is
discovered.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
