This is useful. Thanks.
On 23 January 2016 at 03:34, Dewey Hylton <[email protected]> wrote:
> In the end I think the sql method is the safest and best bet for my use
> case. This was really quick to cobble together, and of course doesn't have
> any protection (eg. from sql-injection or whatever), but as I'm just
> focusing on rolling out new repositories via script I think I'm off to a
> decent start.
>
> %-=
> #!/bin/sh
>
> usage() { echo usage: $0 'archive.fossil "project name" "project
> description"' ; exit 1 ; }
>
> dbname="$1"
> pname="$2"
> pdesc="$3"
>
> test -z "$4" || usage
> test -f "${dbname}" || usage
> test -n "${pname}" || usage
> test -n "${pdesc}" || usage
>
> fossil sqlite -R "${dbname}" "insert or replace into config values
> (\"project-name\", \"${pname}\", now());"
> fossil sqlite -R "${dbname}" "insert or replace into config values
> (\"project-description\", \"${pdesc}\", now());"
> %-=
>
> next steps for me are to pre-populate a README.md, commit, and have /home
> referencing that.
>
> thanks again for your help!
>
> On Thu, Jan 21, 2016 at 11:26 AM, Dewey Hylton <[email protected]>
> wrote:
>
>> the "most official" way is exactly what i was looking for, and i did miss
>> the export/import features. the template feature doesn't appear to do all
>> i'd like (such as modifying the project description). export/import for my
>> purposes would be fiddly because of the byte counts and such. perhaps the
>> sql method is safer in the end due to the byte count issue, and more
>> complete because i'd be able to handle all of these through the one method.
>>
>> i'll definitely play with these different options and see what works best
>> for me.
>>
>> thanks for the suggestions!
>>
>> On Wed, Jan 20, 2016 at 11:13 PM, Ross Berteig <[email protected]>
>> wrote:
>>
>>>
>>> On 1/20/2016 7:33 PM, [email protected] wrote:
>>>
>>>> ....
>>>> i'm currently able to create users and set permissions and such, but
>>>> so far i haven't been able to figure out how to set:
>>>>
>>>> project name
>>>>
>>> > project description
>>> > index page
>>>
>>>>
>>>> how can this be done via command-line? and where is this documented?
>>>>
>>>
>>> The most "official" way is probably through the --template option to the
>>> "fossil new" command. According to "fossil help new", it specifies a
>>> repository to use as a template for the new one, carrying over most
>>> settings from the template to the new repository, except for the list of
>>> normal users.
>>>
>>>
>>> After you have a repository, you can copy the configuration from an
>>> existing one with "fossil configuration pull AREA".
>>>
>>>
>>> A trickier by very scripty approach would also be through the "fossil
>>> configuration" command. It's export, import, and merge subcommands allow
>>> the configuration to be saved and loaded from a file.
>>>
>>> On my clone of the fossil repository, the command:
>>>
>>> C:\...> fossil configuration export project project.txt
>>>
>>> created project.txt containing these lines:
>>>
>>> # The "project" configuration exported from
>>> # repository "C:/Users/Ross/Documents/tmp/fossil4/..\fossil.fossil"
>>> # on 2016-01-21 03:54:09
>>> config /config 40
>>> 1318883638 'project-name' value 'Fossil'
>>> config /config 51
>>> 1318883638 'project-description' value 'Fossil SCM'
>>> config /config 55
>>> 1318883638 'index-page' value '/doc/tip/www/index.wiki'
>>> config /config 32
>>> 1318883638 'manifest' value 'on'
>>>
>>> which by some coincidence covers all three of the items you asked about.
>>> I believe that you can generally edit this file, although you probably have
>>> to adjust the byte count at the end of each "config /config n" line to be
>>> correct for the import or merge subcommands to read the file.
>>>
>>> See the output of fossil help configuration for documentation.
>>>
>>> The configuration is broken into areas which can be handled
>>> individually. The areas are: all email project shun skin ticket user
>>>
>>> Most items have a fairly obvious format in the file, a little
>>> experimentation will lead you where you want to go.
>>>
>>>
>>> i'm sure i'll end up wanting more configuration items, but figure if
>>>> someone can explain this part to me i'll be able to figure out the
>>>> others.
>>>>
>>>
>>> If you have a lot of repositories that should share the same list of
>>> users and related login details, you might be better served by using the
>>> login group mechanism, although it can be quirky to get set up. Once it is
>>> happy, logging in to any repository through the web interface logs you into
>>> all of them.
>>>
>>> --
>>> Ross Berteig [email protected]
>>> Cheshire Engineering Corp. http://www.CheshireEng.com/
>>>
>>> _______________________________________________
>>> fossil-users mailing list
>>> [email protected]
>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>>
>>
>>
>
> _______________________________________________
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
