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 z
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
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 p
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
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 cou
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.
> (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 dis
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
>> wi
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 ch
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 -na
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,
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 appro
>
>
> (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
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
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 a
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 fossi
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
17 matches
Mail list logo
