Не только Git…

(повторение) Git: DVCS

  1. Версионирование
  2. Хранение
  3. Работа с историей изменений в виде орграфа (сети)
    • Ветки
    • Изменение истории
    • …
  4. Информационное пространство:

    • Описание процесса (коммит сообщения)

    • Маркировка отдельных точек (теги)
      • В т. ч. аннотированные и подписанные теги
    • …

Организация взаимодействия при совместной разработке

Модели ведения репозитория

Классическая модель

Открытая модель:

Модель общего хостинга:

Централизованная модель:

Принятие коммитов в репозиторий

Запрос на объединение

(merge request, pull request, …) — часть дисциплины распределённой совместной разработки, в которой предполагается, что у каждого разработчика имеется собственный репозиторий, и только в него можно делать коммиты. Для того, чтобы другой разработчик смог вовремя синхронизировать свой репозиторий с результатами работы первого, его нужно уведомить о том, что работа проделана.

Ревью
(code reviwew) — часть дисциплины совместной разработки, в которой никакой коммит не появляется в истории, пока его не одобрит специально выбранный для этой роли участник. Это может быть лид или просто ещё одинчлен команды
  • Для централизованной модели отсутствие ревью фатально (как и отсутствие многих других элементов дисциплины)

  • Для распределённых моделей ревью «подразумевается» (кто-то же должен сделать merge commit)

Во всех случаях элементы социального взаимодействия (уведомления, обсуждение и т. п.) в самом git не реализованы — это функции хостинга.

Ветки и индивидуальные публичные репозитории — ортогональные сущности

В централизованной схеме ветки играют обе роли.

Пример параллельной разработки

На примере pygments

Работа с несколькими удалёнными репозиториями

git remote (ещё тут)

Cmd и асинхронные сообщения

Проблема: ввод командной строки с помощью readline, подстановка в cmd и прочее — синхронные операции. Предположим, пользователь вводит команду, а в это время прилетает сообщение. Что делать?

Воспользоваться одновременно asyncio и синхронной обработкой ввода нельзя.

Решение: воспользуемся тем, что полученное сообщение надо просто вывести на экран.

TODO надо бы попрозрачнее 

   1 import cmd
   2 import threading
   3 import time
   4 import readline
   5 
   6 
   7 class simple(cmd.Cmd):
   8 
   9     def do_echo(self, arg):
  10         print(arg)
  11 
  12 
  13 def spam(cmdline, timeout, count):
  14     for i in range(count):
  15         time.sleep(timeout)
  16         print(f"\nI'm a message № {i}!\n{cmdline.prompt}{readline.get_line_buffer()}", end="", flush=True)
  17 
  18 
  19 cmdline = simple()
  20 timer = threading.Thread(target=spam, args=(cmdline, 3, 10))
  21 timer.start()
  22 cmdline.cmdloop()

Д/З

Основное задание

  1. Написать простой netcat-образный клиент для «коровьего чата» из задания по прошлой лекции. Достаточно совместить последний пример из лекции и «тупой netcat» из предыдущей. Написать cmd-поддержку команд чата в клиенте и обеспечить completion по именам коров.

    • В login completion должен сначала выполнять cows на сервере, и предлагать результаты оттуда

    • Аналогично, в say completion должен сначала выполнять who на сервере, и предлагать результаты оттуда

  2. Разработку клиента вести согласно дисциплине оформления коммитов в подкаталоге 06_SocialProject отчётного репозитория по Д/З

<!> Обратите внимание на то, что это сравнительно невинное изменение меняет протокол работы с сервером: помимо «просто» сообщений из чата появляется сообщение-ответ на определённую команду-запрос. Самый простой способ не запутаться — это ввести уникальный номер запроса сопровождать ответ им. Например, простое сообщение всегда начинается на пробел, а ответ на команду — на номер поданной в данном сеансе команды.

Регистрация семестрового проекта

  1. Завести один «precious source» репозиторий для merge и публикации проекта и персональные — для разработки (лидеру проекта допустимо вести разработку в отдельной ветке, заводить ещё один репозиторий не надо)
  2. Разработать драфт проектного задания;
    • Постановка решаемой задачи: один абзац или список фич
    • Описание предполагаемых инструментов решения: какие сторонние модули будут использоваться, в рамках каких сервисов (если предполагаются)

    • Макет интерфейса (обратите внимание на то, что от проекта требуется локализация ⇒ какой-то интерфейс с человеком должен быть

      • GUI/TUI — общий вид окошек, что в целом они делаю и как попадают из одного в другое
      • Text — команды, диагностика (в общем плане — когда возникает и как посмотреть), режимы работы
      • …
      • Поместить проектное задание в README (или README.md) публичного репозитория

  3. Зарегистрировать публичный репозиторий проекта в качестве вашего персонального issue на странице репозитория PythonDevelopment2024. В issue указать:

    • Короткую формулировку сути проекта

    • Ссылку на публичный репозиторий проекта

    • Список участников проекта в виде:
      1. ФИО, группа (факультет, если не ВМК) и nick, под которым появляются коммиты в репозитории
      2. ФИО, группа (факультет, если не ВМК) и nick, под которым появляются коммиты в репозитории …

  4. См. требования к защите проекта

LecturesCMC/PythonDevelopment2024/06_SocialProject (последним исправлял пользователь FrBrGeorge 2024-03-25 22:08:03)