Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

On Wed, Jul 27, 2016 at 8:55 PM, Adam Jensen wrote: > Does anyone know of a [libfossil](http://fossil.wanderinghorse.net) > mailing list? Or is it cool to talk about such things here? > No and yes. i'm the originator of libfossil, but a severe inflamed elbow nerve, caused by

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

? -Original Message- From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Adam Jensen Sent: 27. juli 2016 20:56 To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

On 07/27/2016 10:37 AM, Ron W wrote: > On Sun, Jul 24, 2016 at 10:58 PM, Adam Jensen > wrote: > > > [The Session Extension](http://www.sqlite.org/sessionintro.html) pointed > out by Eduardo seems to have a lot of potential. > > "The

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

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

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

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

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

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

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

On Sun, Jul 24, 2016 at 10:58 PM, Adam Jensen wrote: > > [The Session Extension](http://www.sqlite.org/sessionintro.html) pointed > out by Eduardo seems to have a lot of potential. > > "The session extension provides a mechanism for recording changes to > some or all of the

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

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