> (A) Suggest a better name than "fossil trim" How about existing "fossil bundle export"? See (C) discussion below. Having bundles, trim and shun is more confusing for newcomers than single bundle export (or equivalent new command).
(B) Define the syntax of ARGS. This needs some use case discussion first, but I think existing bundle export args will be a good start. What needs to be added is file or directory options. (C) Define a safety mechanism that allows content to be restored if it is accidentally trimmed when there are no other repos available with which to sink. Perhaps the trimmed content gets written into a separate "trash-can" database? This will be solved by extending bundles functionality. You effectively create a trimmed repo with 'fossil bundle export --standalone' (I realise standalone is supposed to mean something else in current bundle world, but it currently doesn't work anyway). In this context it will create a standalone repo that can be opened and worked on its own. Regarding use cases, I think there are 2 orthogonal categories of use which may intersect or combine: 1. Strip out files and directories, i.e. get rid of all artifacts that don't relate to this files (or export only those that touch these files). Obviously for sensitive or proprietary information, but this can be useful for repo 'sharding' where only a subdirectory tree can be exported for someone to develop on, or to manage third party libraries. So we'd need a file glob in args here, maybe even as a file checked in .fossil_options like empty-dirs for lots of trimming, and so it can be set for synching once we get to that. It would be nice if glob worked from both include or exclude perspective (export only these files, or export all files except these). 2. Strip out history of work, i.e. --from --to tags, --branch. For performance reasons on large repos, as it is unlikely that anything older than xxx years or months is required for active development. Or perhaps to submit drive-by patches or features, which bundle currently covers. Or rudimentary permissions management, where some devs are not to see somebody else's sensitive work in another branch, but others should. Args here would need to be recognised as hashes, tags or dates. I would also think that this kind of export should ensure that if a subset of artifacts or commits is exported, all the files touched must check out. Perhaps an initial checkin that adds the missing file, is tagged in a special way and never syncs anywhere. A special case of 'fossil rebase' :) The alternative is that the file simply doesn't check out with a warning, which is the current bundle export functionality and is not that useful. I am much more interested in 1. Don't care that much about 2. - but I can use branch export where all the files touched are guaranteed to check out, for subcontracting type work. I think if this functionality or some subset of it does get implemented, it would make Fossil much more malleable for users coming from Git world and make big differences between the two (sharding vs replication, rewriting history) matter less. Cheers, Steve _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
