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
