Re: [fossil-users] Purging data from Fossil
Thus said David Mason on Tue, 26 Jul 2016 16:41:29 -0400: > 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. Do they actually need the fossil (e.g. all the history of the changes), or would an export (e.g. fossil zip, followed by removing files) be sufficient? Thanks, Andy -- TAI64 timestamp: 4000579902c4 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Purging data from Fossil
On Jul 27, 2016, at 6:55 AM, Steve Stefanovich wrote: > >> (A) Suggest a better name than "fossil trim" > > (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. Yes, it would indeed be nice if “standalone” bundles truly were standalone, this whole thread notwithstanding. It’s a misleading option name as it stands. That by itself wouldn’t suffice to provide my wished-for repo sharding feature, since bundles currently don’t have a way to include artifacts based on a file path pattern, but that should be a straightforward extension, since Fossil stores file artifacts based on their full path. > So we'd need a file glob in args here Both glob and regex patterns are helpful, each in different cases. Classic Unix tools that support both usually accept glob patterns by default, then accept a -r, -R, or --regex flag to make it accept REs instead. Obviously we can’t use -R for this with Fossil, but double-dash flags are commonly used in Fossil for such non-default features. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Purging data from Fossil
On Jul 27, 2016, at 12:41 AM, Stephan Beal wrote: > > On Tue, Jul 26, 2016 at 11:12 PM, Eric Rubin-Smith wrote: > > this sounds more like it might belong in a "filtered export” Perhaps that would also allow repository sharding. That is, given a repository that contains multiple independent projects — as may happen when converting from another VCS, or just due to naive use of Fossil — you may wish to export all but one of those projects to independent repos, then trim them out of the main repo. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Purging data from Fossil
On 7/27/16, David Mason wrote: > On 26 July 2016 at 17:13, Richard Hipp wrote: > >> SELECT DISTINCT uuid >> FROM blob, mlink, filename >> > > Works a charm (18 UUIDs show up). Now if there were a way to shun from the > command line, I'd be golden. The entry box on the /shun webpage allows you to past all 18 SHA1 hashes in a single go. BTW: Be sure to "fossil rebuild" after shunning. That extra step is necessary to fully purge the unwanted artifacts. Also look into using the "fossil scrub" command on any repo that you want to send to unprivileged users. -- 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
Re: [fossil-users] Purging data from Fossil
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 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 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
Re: [fossil-users] Purging data from Fossil
On 26 July 2016 at 17:13, Richard Hipp wrote: > SELECT DISTINCT uuid > FROM blob, mlink, filename > Works a charm (18 UUIDs show up). Now if there were a way to shun from the command line, I'd be golden. BTW, swapping "uuid" and "filename.name" in the SQL lists the files that match a uuid. Thanks ../Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Purging data from Fossil
> (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
Re: [fossil-users] Purging data from Fossil
On Tue, Jul 26, 2016 at 11:12 PM, Eric Rubin-Smith wrote: > >> (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? >> > > You might consider this from the converse perspective, allowing 'fossil > export' to a new fossil repo, but specifying some sort of complex boolean > selector on export. Then you at least get the safety for free since the > source repo is only read from. > fwiw, that was also my gut reaction: this sounds more like it might belong in a "filtered export" -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Purging data from Fossil
I forgot to do something about the `to standard output` bit. We could leave it like that, but if the user forgets to redirect, he'll get a messy terminal. Perhaps we could add a final argument: FILE, so we'd have: Usage: fossil export FORMAT ?OPTIONS? ?REPOSITORY? ?FILE? Write an export of all check-ins to FILE in one of the following repository FORMATs: --fossil the fossil format --gitthe git-fast-export format If FILE is not specified or is "-", write export check-ins to standard output. On 27 July 2016 at 06:04, Barry Arthur wrote: > I like the `export` idea. It solves the `trash-can` problem and it's a > feature that has been (directly or indirectly) requested a few times over > the years. That covers (a) and (c), only leaving: > > (B) Define the syntax of ARGS. > > > Let me begin that bikeshed with: > > Existing tools: > > find . -type f -name "*.txt" ! -path "./Movies/*" ! -path "./Downloads/*" > ! -path "./Music/*" > rsync -avz --exclude 'dir1' --exclude file1.txt --exclude dir3/*.txt > source/ destination/ > rsync -avz --exclude-from 'exclude-list.txt' source/ destination/ > > Fossil proposal: > > Usage: fossil export FORMAT ?OPTIONS? ?REPOSITORY? > > Write an export of all check-ins to standard output in one of the following > repository formats: > --fossil the fossil format > --gitthe git-fast-export format > > Run this command within a checkout. Or use the -R or --repository > option to specify a Fossil repository to be exported. > > Only check-ins are exported using --git. Git does not support tickets > or wiki or events or attachments, so none of those are exported. > > If the "--import-marks FILE" option is used, it contains a list of > rids to skip. > > If the "--export-marks FILE" option is used, the rid of all commits and > blobs written on exit for use with "--import-marks" on the next run. > > Use the "--exclude GLOB" option to prevent matching files and/or > directories > from being exported. It can be used as many times as you like to build up > the list of files to exclude. > > Use the "--exclude-from FILE" option to exclude a large number of GLOB > patterns conveniently. > > Options: > --exclude GLOB don't export GLOB > --exclude-from FILE don't export GLOBS within FILE > --export-marks FILE export rids of exported data to FILE > --import-marks FILE read rids of data to ignore from FILE > --repository|-R REPOSITORY export the given REPOSITORY > > Have at it! > > On 27 July 2016 at 05:13, Richard Hipp wrote: > >> On 7/26/16, David Mason wrote: >> > Is there any way to find all the artifacts that correspond to a given >> > pathname? Then I could shun those. >> >> SELECT DISTINCT uuid >> FROM blob, mlink, filename >> WHERE blob.rid=mlink.fid >>AND mlink.fnid=filename.fnid >>AND filename.name=$NAME; >> >> Fill in $NAME appropriately, of course. >> >> -- >> 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
Re: [fossil-users] Purging data from Fossil
I like the `export` idea. It solves the `trash-can` problem and it's a feature that has been (directly or indirectly) requested a few times over the years. That covers (a) and (c), only leaving: (B) Define the syntax of ARGS. Let me begin that bikeshed with: Existing tools: find . -type f -name "*.txt" ! -path "./Movies/*" ! -path "./Downloads/*" ! -path "./Music/*" rsync -avz --exclude 'dir1' --exclude file1.txt --exclude dir3/*.txt source/ destination/ rsync -avz --exclude-from 'exclude-list.txt' source/ destination/ Fossil proposal: Usage: fossil export FORMAT ?OPTIONS? ?REPOSITORY? Write an export of all check-ins to standard output in one of the following repository formats: --fossil the fossil format --gitthe git-fast-export format Run this command within a checkout. Or use the -R or --repository option to specify a Fossil repository to be exported. Only check-ins are exported using --git. Git does not support tickets or wiki or events or attachments, so none of those are exported. If the "--import-marks FILE" option is used, it contains a list of rids to skip. If the "--export-marks FILE" option is used, the rid of all commits and blobs written on exit for use with "--import-marks" on the next run. Use the "--exclude GLOB" option to prevent matching files and/or directories from being exported. It can be used as many times as you like to build up the list of files to exclude. Use the "--exclude-from FILE" option to exclude a large number of GLOB patterns conveniently. Options: --exclude GLOB don't export GLOB --exclude-from FILE don't export GLOBS within FILE --export-marks FILE export rids of exported data to FILE --import-marks FILE read rids of data to ignore from FILE --repository|-R REPOSITORY export the given REPOSITORY Have at it! On 27 July 2016 at 05:13, Richard Hipp wrote: > On 7/26/16, David Mason wrote: > > Is there any way to find all the artifacts that correspond to a given > > pathname? Then I could shun those. > > SELECT DISTINCT uuid > FROM blob, mlink, filename > WHERE blob.rid=mlink.fid >AND mlink.fnid=filename.fnid >AND filename.name=$NAME; > > Fill in $NAME appropriately, of course. > > -- > 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
Re: [fossil-users] Purging data from Fossil
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 Hippwrote 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 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
Re: [fossil-users] Purging data from Fossil
On 7/26/16, David Mason wrote: > Is there any way to find all the artifacts that correspond to a given > pathname? Then I could shun those. SELECT DISTINCT uuid FROM blob, mlink, filename WHERE blob.rid=mlink.fid AND mlink.fnid=filename.fnid AND filename.name=$NAME; Fill in $NAME appropriately, of course. -- 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
Re: [fossil-users] Purging data from Fossil
> > > (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? > You might consider this from the converse perspective, allowing 'fossil export' to a new fossil repo, but specifying some sort of complex boolean selector on export. Then you at least get the safety for free since the source repo is only read from. Eric ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Purging data from Fossil
Is there any way to find all the artifacts that correspond to a given pathname? Then I could shun those. On 26 July 2016 at 16:51, Richard Hipp wrote: > On 7/26/16, David Mason 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 > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Purging data from Fossil
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 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
Re: [fossil-users] Purging data from Fossil
On 7/26/16, David Mason 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
[fossil-users] Purging data from Fossil
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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users