On Dec 26, 2017, at 4:45 PM, Olivier Mascia <[email protected]> wrote:
>
>> Le 27 déc. 2017 à 00:39, Warren Young <[email protected]> a écrit :
>>
>> Until drh ships Fossil 2.5, you’ll have to either stick with that workaround
>> or build your own fossil.exe against the trunk code.
>
> Makes it clear. Thanks.
Well, “clear” is a charitable description. Thank you for being nice. :)
I find my reply less than clear. Let me make a few clarifications.
These improvements to the way Fossil does skinning are only about a month old,
so you need a Fossil binary that’s newer than that to make use of the skin
configuration you get when cloning the remote repository.
This does not mean that Fossil 2.4 cannot make use of the current sqlite.org
repository. It just means that sqlite.org is making use of unreleased features
already. (Again part of the “eat your own dog food” standard practice.)
There is a second workaround:
c:\> fossil conf reset skin
That tells your local Fossil to throw away the skin configuration it got as
part of the clone and just use what’s built into your local fossil.exe.
That’s one of the cool things about Fossil as compared to GitHub: not only can
you skin it however you like, a clone needn’t necessarily have the same skin as
the repository it cloned from. The only time they’re synchronized
automatically is on the initial clone. After that, you have to *ask* for a
re-sync:
c:\> fossil conf pull skin
or:
c:\> fossil conf pull all
to overwrite all the other locally-configurable bits.
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
