I have only known about Fossil for a week now, but I would like to humbly suggest "fossil strip ARGS...". I will leave the ARGS part up to the experts. I also like the idea Eric had with thinking about it in a different perspective and making it an export option. But again, I only just arrived, and I'm still learning the syntax! So feel free to ignore me :)
Cheers, Brian Otto https://www.grokbb.com ---- On Tue, 26 Jul 2016 14:04:59 -0700 Richard Hipp <d...@sqlite.org>wrote ---- Further thoughts: With shunning, Fossil remembers the SHA1 hashes of the shunned artifacts so that they can never again be received by subsequent pulls. It seems like this is more than you need. Suppose we created a new command "fossil trim ARGS..." This new command would remove selected artifacts from the local copy of the repository, but the removal would be temporary. The artifacts would reappear the next time the local repository is synced with some other repo that holds the artifacts. (The removal would, of course, be permanent if there were no other copies of the repo to sync with.) It seems like the "trim" command might serve several purposes: (1) Allow the creation of a repo that omits selected historical information that one does not want to share. (2) Allows putting Fossil into a weird state in order to stress the sync logic for testing purposes. I could have made use of this feature for purpose (1) last week, had it been available. So I am now officially interested in adding it. The ARGS part would embody several options for doing things like removing all instances of a specific file, or all check-ins within a range of dates, all tickets matching some criteria, all wiki pages whose names match a GLOB pattern, etc. The problem I had last week was I needed a cut-down instance of a repository that only contained data for two specific check-ins out of around 3000. Community members, I want your help as follows: (A) Suggest a better name than "fossil trim" (B) Define the syntax of ARGS. (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? On 7/26/16, David Mason <dma...@ryerson.ca> wrote: > I have a problem. > > I use fossil for my courses - one I've used for 4 years. In each year > there are grades files (with student names, student numbers and grades), > and they get changed and committed over the semester, so there are many > versions in the fossil (hundreds of checkins). > > I want to share these fossils with some people who cannot be allowed to see > the grades files. So I need to remove the data. I could shun the artifacts > and rebuild (and, in fact that's what I started to do), but finding all the > versions of the files seems rather daunting, and it appears I can only shun > from the UI, so I can't even write a script to do it. > > Any ideas on how to clean this up? fossil purge looked like it might help, > but then not so much... > > BTW, on the shun page, when it lists pending shuns at the bottom of the > page, it would be very convenient if it listed the files that correspond to > that hash (probably only 1, modulo renaming, but useful regardless). > > Thanks for any help! > > ../Dave > -- D. Richard Hipp d...@sqlite.org _______________________________________________ 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
