Нет сжатия локальной базы репозитория
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 停滞
- 技術スタック
- git
- 領域
- tooling
調査の方向性
リポジトリのファイル、テスト、またはエントリポイントは指定されていません。まず既存のエクスポートフローとその Git 操作を見つけ、要求されている定期的な git push とローカルリポジトリの圧縮を、GitGui の圧縮動作と比較してください。完了条件には、設定可能な間隔の定義と、両方の操作について動作を検証済みであることを含める必要があります。
索引モデルが issue の本文から書いたものです。
説明
Существует проблема
При большом числе инкрементальных выгрузок, или большом числе измененных объектов
последующие выгрузки начинают резко тормозить или выгрузка останавливается вовсе...
Пример - 200 версий... (на моей базе и компе примерно 40-50 версий в час - план 4-5 ч.)
запущено вечером, чтобы к утру всё прогрузилось...
в результате... утром обработка всё ещё идёт...
смотрим файл VERSION - только 37 версий прошло за 12 ч !? и в git ничего не выгрузилось!
Открываем репозиторий через GitGui чтобы выгрузить изменения...
сразу появляется окно - База данных репозитория требует сжатия (Compress DataBase) ... Ок
это же окно можно открыть через Repository - Compress DataBase
----- после сжатия (каждый час, делал параллельно с gitsync)
--- "оставшиеся" 150 изменений выгрузились "с плановой скоростью" за 3ч.
Хотелось бы иметь следующую функциональность
- после каждых 10 (или N) изменений - делать push в git-репозиторий
- делать сжатие (compress DataBase) локального репозитория... каждый раз после п.1
Вариант реализации [...]
-
для отправки - добавлять git push не в конце, а через каждые 10-20 изменений
( лучше конечно сделать и отдельный ключ ,
т.е. сейчас он равен 0 (не определен) - push делается только в конце распаковки всех изменений -
сжатие - после каждых N изменений из п.1 (или в конце)
- добавить команду git fsck (для каталога локального репозитория)
(но я не уверен, что именно эта команда, извините есть что)
Дополнительный контекст
требование сжатия открываются в программе gitgui v 0.21 для git version 2.41.1 для windows.1
(но и раньше в 2020 г на более ранних версиях такое же было)
Спасибо за gitsync, давно им пользуюсь,
некоторые неудобства приходится обходить
через свои выгрузки на oscript и выполнение команд git
хотелось бы "улучшить" ситуацию для загрузки большого числа изменений
Живой пример - команда 4-5 разработчиков
- каждый день делает 10-20 изменений (а то и больше) в хранилище,
за месяц (20-22 дня) это 200-440, за год х12 = 2400 - 5 280 изменений!
При начале использования GitSync для база за пару - тройку лет
загрузка превращается в боль на месяц-другой.
- 主要言語
- 1C Enterprise
- スター
- 334
- フォーク
- 98
- 平均マージ
- 14時間 29分
- マージ済み PR（30日）
- 11
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
oscript-library/gitsync のほかの issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
oscript-library/gitsync#355 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
oscript-library/gitsync#241 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
oscript-library/gitsync#388 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
oscript-library/gitsync#366 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
oscript-library/gitsync#361 · コメント 6 件 ·
メンテナーはふだん 1 日以内に返信
oscript-library/gitsync の issue をすべて見る
似ている issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 84/100
NVIDIA/DeepStream#78 ·
-
documentation good first issue help wanted
難易度 1/5 1〜3時間 初心者へのやさしさ 85/100
zmo2s/agent-toolbox#23 ·
-
raised-by:worker
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
medici-finance/assay#2486 ·
メンテナーはふだん 1 日以内に返信
-
bug traffic
難易度 2/5 1時間未満 初心者へのやさしさ 74/100
-
enhancement good first issue Stellar Wave trivial
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
StellarCanary/ProtocolCanary-Fixtures#258 ·
メンテナーはふだん 1 日以内に返信