App-reposdb

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

VERSION
    This document describes version 0.007 of App::reposdb (from Perl
    distribution App-reposdb), released on 2020-10-10.

SYNOPSIS
    See reposdb.

DESCRIPTION
    "repos.db" is a SQLite database that lists repository names along with
    some extra data. They have various uses, but my first use-case for this
    is to store last commit/status/pull time (updated via a post-commit git
    hook or "gitwrap"). This is useful to speed up like syncing of
    repositories in "Git::Bunch" that wants to find out which of the
    hundreds/thousand+ git repositories are "the most recently used" to
    prioritize these repositories first. Using information from "repos.db"
    is faster than having to "git status" or even stat() each repository.

FUNCTIONS
  add_repo_tag
    Usage:

lib/App/reposdb.pm  view on Meta::CPAN

our %SPEC;

$SPEC{':package'} = {
    v => 1.1,
    summary => 'Manipulate repos.db',
    description => <<'_',

`repos.db` is a SQLite database that lists repository names along with some
extra data. They have various uses, but my first use-case for this is to store
last commit/status/pull time (updated via a post-commit git hook or `gitwrap`).
This is useful to speed up like syncing of repositories in `Git::Bunch` that
wants to find out which of the hundreds/thousand+ git repositories are "the most
recently used" to prioritize these repositories first. Using information from
`repos.db` is faster than having to `git status` or even stat() each repository.

_
};

sub _complete_repo {
    my %args = @_;

lib/App/reposdb.pm  view on Meta::CPAN

=head1 SYNOPSIS

See L<reposdb>.

=head1 DESCRIPTION


C<repos.db> is a SQLite database that lists repository names along with some
extra data. They have various uses, but my first use-case for this is to store
last commit/status/pull time (updated via a post-commit git hook or C<gitwrap>).
This is useful to speed up like syncing of repositories in C<Git::Bunch> that
wants to find out which of the hundreds/thousand+ git repositories are "the most
recently used" to prioritize these repositories first. Using information from
C<repos.db> is faster than having to C<git status> or even stat() each repository.

=head1 FUNCTIONS


=head2 add_repo_tag

script/_reposdb-inline  view on Meta::CPAN

# ABSTRACT: Completer script for reposdb-inline

use 5.010;
use strict;
use warnings;

die "Please run this script under shell completion\n" unless $ENV{COMP_LINE} || $ENV{COMMAND_LINE};

my $args = {program_name=>"reposdb-inline",read_config=>0,read_env=>0,skip_format=>undef,subcommands=>{ls=>"/App/reposdb/list_repos","remove-all-tags"=>"/App/reposdb/remove_all_repo_tags","remove-tag"=>"/App/reposdb/remove_repo_tag",touch=>"/App/repo...

my $meta = {_orig_args_as=>undef,_orig_result_naked=>undef,args_as=>"hash",description=>"\n`repos.db` is a SQLite database that lists repository names along with some\nextra data. They have various uses, but my first use-case for this is to store\nla...

my $sc_metas = do{my$a={ls=>{_orig_args_as=>undef,_orig_result_naked=>undef,args=>{detail=>{cmdline_aliases=>{l=>{}},schema=>["bool",{},{}],tags=>["category:field-selection"]},has_tags=>{element_completion=>sub{package App::reposdb;use warnings;use s...

my $copts = {format=>{default=>undef,getopt=>"format=s",handler=>sub{package Perinci::CmdLine::Base;use warnings;use strict;no feature;use feature ':5.10';my($go, $val, $r) = @_;$$r{'format'} = $val},is_settable_via_config=>1,schema=>["str*","in",["t...

my $r = {};

# get words
my $shell;
my ($words, $cword);

script/_reposdb-inline  view on Meta::CPAN

#adjust with your personal style.
#
#B<Per-package settings.> Each importer package can use its own format/layout,
#output. For example, a module that is migrated from Log::Any uses Log::Any-style
#logging, while another uses native Log::ger style, and yet some other uses block
#formatting like Log::Contextual. This eases code migration and teamwork. Each
#module author can preserve her own logging style, if wanted, and all the modules
#still use the same framework.
#
#B<Dynamic.> Outputs and levels can be changed anytime during run-time and logger
#routines will be updated automatically. This is useful in situation like a
#long-running server application: you can turn on tracing logs temporarily to
#debug problems, then turn them off again, without restarting your server.
#
#B<Interoperability.> There are modules to interop with Log::Any, either consume
#Log::Any logs (see L<Log::Any::Adapter::LogGer>) or produce logs to be consumed
#by Log::Any (see L<Log::ger::Output::LogAny>).
#
#B<Many output modules and plugins.> See C<Log::ger::Output::*>,
#C<Log::ger::Format::*>, C<Log::ger::Layout::*>, C<Log::ger::Plugin::*>. Writing
#an output module in Log::ger is easier than writing a Log::Any::Adapter::*.

script/reposdb-inline  view on Meta::CPAN

 % reposdb-inline touch [--commit-time] [--config-path=path+]
     [--config-profile=profile] [--format=name] [--json] [--(no)naked-res]
     [--no-config] [--no-env] [--page-result[=program]] [--pull-time]
     [--reposdb-path=s] [--status-time] [--to=s] [--view-result[=program]]
     [repo]

=head1 DESCRIPTION

C<repos.db> is a SQLite database that lists repository names along with some
extra data. They have various uses, but my first use-case for this is to store
last commit/status/pull time (updated via a post-commit git hook or C<gitwrap>).
This is useful to speed up like syncing of repositories in C<Git::Bunch> that
wants to find out which of the hundreds/thousand+ git repositories are "the most
recently used" to prioritize these repositories first. Using information from
C<repos.db> is faster than having to C<git status> or even stat() each repository.

=head1 SUBCOMMANDS

=head2 B<ls>

List repositories registered in repos.db.