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...
It is theoretically possible to do this with the current data design. It would really just be a few SQL statements, with the corresponding C code to handling the user interface. But that code does not currently exist. Adding code to do this would make a good student project. Do you have any students willing to undertake it? :-) > > 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). The "shun" table currently has the "scom" field which is intended to be human-readable text that explains why the shun occurred. Probably you would want to add another field to be the filename of the object shunned. This is doable. But, again, the code is not yet in place. -- 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
