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
