From 17e3e076fd304d60a522cae6aa63fe8a795483d7 Mon Sep 17 00:00:00 2001 From: Vladimir Krutkin Date: Wed, 20 Mar 2024 17:18:25 +0300 Subject: [PATCH] Typos --- docs/papers/hbs2-git-doc-0.24.1.tex | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/papers/hbs2-git-doc-0.24.1.tex b/docs/papers/hbs2-git-doc-0.24.1.tex index f5b6cc6d..c32e4c03 100644 --- a/docs/papers/hbs2-git-doc-0.24.1.tex +++ b/docs/papers/hbs2-git-doc-0.24.1.tex @@ -739,7 +739,7 @@ hbs2 sigil check my.sigil \end{verbatim} -Это похоже на сертификат и, в некотором роде, им является но специально названо иначе, что бы не +Это похоже на сертификат и, в некотором роде, им является, но специально названо иначе, что бы не путать с сертификатами X.509 или какими-то еще. Создать <> можно при помощи команды @@ -785,7 +785,7 @@ export tags Означает, что каждая операция \texttt{git push} которая на деле является операцией EXPORT -- экспортирует все объекты, перечисленные в конфигурации: бранч master, бранч main, бранч, на который -указывает \texttt{HEAD} и бранчи, для которых выполняется \texttt{git push}. +указывает \texttt{HEAD}, и бранчи, для которых выполняется \texttt{git push}. Если указать, например, @@ -811,7 +811,7 @@ export exclude "refs/heads/*" \paragraph{Синхронизация с hbs2-fixer} \texttt{hbs2-fixer} принимает в качестве параметра \texttt{-c} имя файла конфигурации. -Формат конфигурации -- Schema-подобный DSL, который позволяет настраивать обработчики +Формат конфигурации -- Scheme-подобный DSL, который позволяет настраивать обработчики событий и действия по ним. Примеры файлов конфигурации находятся в \texttt{hbs2-fixer/examples}. Рассмотрим простой пример: @@ -897,7 +897,7 @@ $ cat simple.scm \end{verbatim} -Теперь имя данный конфигурационный файл, запустим его: +Теперь, имея данный конфигурационный файл, запустим его: \begin{verbatim} hbs2-fixer -c ./simple.scm @@ -1137,14 +1137,14 @@ BTThPdHKF8XnEq4m6wzbKHKA6geLFK4ydYhBXAqBdHSP \end{verbatim} Однако, теперь это не ссылка типа reflog, а ссылка типа lwwref. Это другой тип данных, - и значение типа \texttt{lwwref(BTThPdHKF8XnEq4m6wzbKHKA6geLFK4ydYhBXAqBdHSP} + и значение типа \texttt{lwwref(BTThPdHKF8XnEq4m6wzbKHKA6geLFK4ydYhBXAqBdHSP)} имеет другой хэш. Таким образом, старая версия hbs2-git продолжит работать с рефлогом \texttt{BTThPdHKF8XnEq4m6wzbKHKA6geLFK4ydYhBXAqBdHSP}, - новая же версия использует lwwref. Ассоциированный с данным lwwref можно посмотреть, например, так: + новая же версия использует lwwref. Ассоциированный с данным lwwref рефлог можно посмотреть, например, так: \begin{verbatim} $ git hbs2 tools show-remotes @@ -1152,7 +1152,7 @@ $ git hbs2 tools show-remotes \end{verbatim} Данная команда покажет, какие lwwref используются в качестве git remote в данном репозитории, -и какие у них версии lwwref и какие значения. +а также версии и значения этих lwwref. Каждая транзакция $T_n$ содержит полный самодостаточный снимок репозитория, т.е технически возможно развернуть репозиторий, имея только транзакцию. @@ -1169,7 +1169,7 @@ $GitObjectPack_n$, полученных при помощи команды \text \item git порождает огромное количество слабо различающихся маленьких объектов, следовательно, огромную избыточность данных. Лучше всего свои объекты упаковывает сам git, используя, в частности, бинарные дельты. - \item каждый отдельный объект (\textit{блок}) подразумевает, в общем случае, несколько + \item Каждый отдельный объект (\textit{блок}) подразумевает, в общем случае, несколько сетевых запросов для получения: запрос размера, запрос чанков, ответ. Таким образом, повышение количества объектов ведёт к ухудшению скорости синхронизации. \item Выше скорость импорта объектов в репозиторий, так как он выполняется стандартной @@ -1204,7 +1204,7 @@ $GitObjectPack_n$, полученных при помощи команды \text Для <<новых>> деревьев будет сгенерирован новый секрет. Нет смысла обновлять <<старые>> секреты, так как уже записанная в HBS2 информация никуда оттуда уже -не денется, будут ли обновлены перегенерированы старые секреты или нет --- данные, зашифрованные +не денется, будут ли обновлены старые секреты или нет --- данные, зашифрованные <<старыми>> секретами все равно останутся в системе. Заметим, что удаление участника из группового ключа лишит его доступа к последующим изменениям, но @@ -1357,14 +1357,14 @@ hbs2-keyman не отображает секретные ключи, тольк \section{Поддержка возможностей git} -пока не поддерживаются подписанные теги. По крайней мере не тестировались. +Пока не поддерживаются подписанные теги. По крайней мере не тестировались. \section{Разное} В документации или где-то еще могут спорадически появляться префиксы hbs21 (hbs21://). -Этот префикс был присвоен новому протоколу hbs2, что бы он не интерферировал -со старым и можно было бы одновременно пользоваться двумя версиями hbs2-git. +Этот префикс был присвоен новому протоколу hbs2, чтобы он не интерферировал +со старым, и можно было бы одновременно пользоваться двумя версиями hbs2-git. После релиза новой версии и прекращении поддержки старой -- данный префикс не используется, однако должен пониматься hbs2-git (вместо hbs2://)