My use case is similar to what Adam describes. I already wrote a mail about this some time ago, but as I was absent last month, I couldn’t look at this feature in more detail until now. To reiterate, we use Fossil for collaborative paper writing. There are a lot of supplementary data that is useful to have around in the repository, but which does not need to be versioned (reports, current datasets etc.). It would be very useful to us if we had the ability to make unversioned files part of the checkout as a per-project option.
@Richard (or others), how would you estimate the difficulty of adding this functionality? If I understand correctly, one would need to add a new field for storing the path of the unversioned file as well as logic that writes these files on checkout. I assume that no changes would be needed for the sync protocol itself? Best, Taras > On 31 Aug 2016, at 02:29, Adam Jensen <han...@riseup.net> wrote: > > On 08/30/2016 02:31 PM, Richard Hipp wrote: >> A new feature of Fossil (currently unreleased and only available to >> people who are willing to recompile the code on trunk) is "unversioned >> files". >> >> https://www.fossil-scm.org/fossil/doc/trunk/www/unvers.wiki > > Hey, cool. This seems like a move in a good direction. I can imagine > scenarios where some files are relevant to a project, and it would be > convenient to bundle them into the Fossil database for backup and > syncing, but saving the change history of those files doesn't really > make much sense. For example, a project might have an associated SQLite > database and it might be convenient to have a content .dump of that > database and possibly a few Session Extension[1] changesets stored in > the repository (and sync'able). > > [1]: https://www.sqlite.org/sessionintro.html > > In this case, it seems like the ability to check-in, check-out, and > remove these unversioned files from the repository would be needed (for > it to make sense). In an example work-flow, perhaps only the most recent > database .dump would be kept. After a few chagesets are accumulated and > a new common database state is agreed upon, a new .dump could be > checked-in and the old dumps and chagesets could be removed (if they're > no longer needed). > > The current implementation doesn't look like it would support this > (above) scenario. > > "Unversioned files are not a part of a check-out. Unversioned files are > intended to be accessible as web pages..." > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
