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 <dewey.hyl...@gmail.com>
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 <r...@cheshireeng.com>
> wrote:
>
>>
>> On 1/20/2016 7:33 PM, dewey.hyl...@gmail.com 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 r...@cheshireeng.com
>> Cheshire Engineering Corp. http://www.CheshireEng.com/
>>
>> _______________________________________________
>> 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
