Another nice use of this capability would be to make nested fossils - one of the really nice unique features of fossil.
Eg. fossil X with directories A, B and C (and lots of files and commits). If you could (via export or strip) C into C.fossil and everything *but* C into RestX.fossil then you could now open C.fossil nested under a RestX opened directory and the fossils can be shared and maintained separately... So ARGS should allow you to include or exclude a directory and everything under it. On 26 July 2016 at 17:04, 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
