Как DVCS может помочь научному программированию?

Question

Я делаю некоторую предварительную работу по изучению того, как DVCS (например, Git, Hg, Bazar) может помочь в процессе научного программирования, особенно для аспирантов. Я думаю, что у меня для этого достаточно хорошая позиция, поскольку я программирую уже несколько лет и в настоящее время начинаю магистерскую программу по естествознанию. Цель состоит в том, чтобы сделать краткую презентацию об этом через месяц или два.

Насколько я понимаю, помимо очевидного преимущества контроля источников, DVCS в настоящее время обеспечивает следующие улучшения в повседневной жизни аспиранта:

1. Ветвление:

   Это большой. Из наблюдения практики DVCS ясно, что дешевое ветвление в основном поощряет экспериментирование новых функций. Научное программирование - это ВСЕ о экспериментах. Различные ветви могут быть созданы для настройки параметров или алгоритмов. Это особенно важно, потому что большинство научных кодов не видели ни одной рефакторинга в течение своей жизни (большинство аспирантов даже не знают, что это такое), поэтому способность переходить в разные ветви принесет какой-то метод в типичное безумие. Быстрые коммиты также могут означать использование коммитов в качестве суррогата для лабораторных тетрадей. Результаты вычислений могут быть привязаны к конкретным хеш-кодам коммитов для воспроизводимых исследований.

2. Отправка на серверы:

   Поскольку в настоящее время большинство научного кода выполняется в каком-то кластере, DVCS можно использовать как своего рода более продвинутый Rsync, который многие уже используют для передачи «производственного» кода в кластеры HPC. Это в сочетании с ветвлением позволяет легко запускать несколько версий кода, не оставляя

3. Совместная работа:

   Должен ли я сказать больше? Работы с несколькими авторами выполняются в точности как небольшие проекты с открытым исходным кодом. Совместная работа над статьями должна быть естественной, когда все авторы пишут на LaTex, с дополнительными сложностями, если написание выполняется в чем-то вроде Word. Здесь комментарии коммитов могут сыграть большую роль.

Мой вопрос: как вы думаете, что DVCS может помочь научным программистам? Я вижу много разговоров о переходе к управлению исходным кодом в сообществе, но большинство все еще изучают Subversion. Из моих кратких заметок кажется, что DVCS должен быть идеальной парадигмой рабочего процесса для новых аспирантов. Мое мышление ошибочно? Или же научное кодирование просто слишком сильно отстает, чтобы даже услышать инструментов DVCS?

---

Связанный:

• Практика по программированию в научной среде

Answer 1

Обучение - это реальная проблема. Я знаю немало физиков элементарных частиц (большая наука с большими проектами программирования), чьи общие знания об управлении исходными кодами - как запускать наивные версии cvs checkout, cvs update и cvs commit.

Да, CVS. Я знаю руководителя группы разработчиков программного обеспечения, который из-за этих людей отложил переход на Subversion.

На следующем уровне квалификации они также знают команды diff и stat и способы указания веток или тегов, но могут избегать создания или объединения ветвей.

Если вы планируете внедрить DVCS, запланируйте интенсивную, постоянную программу обучения и поддержки. Ученые (или, по крайней мере, физики), как правило, мало формально обучаются информатике и могут иметь только смутное представление о программном процессе.

Answer 2

Относительно ваших основных пунктов:

• «очевидное преимущество DVCS»: следует повторить, что, особенно в академической среде с потенциально строгими правилами ИТ для не , допускающими внешнее соединение, DVCS позволяет работать с локальным репозиторий. Это означает, что вам не нужно «подключаться» к одному центральному репо, чтобы получить доступ ко всей истории проекта, и это может быть основным вкладом DVCS в научных программистов.

Но это также означает, что у вас должна быть какая-то политика, чтобы позволить любой данной работе «собраться вместе» и объединиться в один репозиторий, что не означает, что будет только одна «центральная» база: можно представить несколько центральных репо для нескольких крупных проектов. Тем не менее, для этого требуется администрация (не следует недооценивать).

И этот процесс "консолидации" может быть довольно сложным из-за вашего основного первого пункта:

• ветвление: студент должен тщательно ветвиться (так как это так просто). Я видел свою долю веток с именами 'toto', 'Monday', 'myName', ...: однажды опубликованная в другом (более центральном) репо, что мы должны делать с ними? Если более 20 веток должны быть объединены, чтобы завершить один общий код, ... процесс может стать подверженным ошибкам очень быстро.

Быстрые комментарии по другим вашим пунктам:

• развертывание (то, что вы называете «отправкой на сервер»): да, DVCS можно использовать для какого-либо развертывания, но это означает, что вы организовали репо с включением какого-то выпуска » компонент " (набор файлов, который вы хотите отправить на сервер), и вы вернули их версии. А управление выпуском включает в себя множество других шагов, которые невозможно запомнить в DVCS, например, процесс де-вариабилизации, когда вы заменяете переменную в файлах конфигурации фактическими значениями, адаптированными к целевому серверу (номера портов, локальные пути, ...) , Вы можете попытаться управлять этими файлами конфигурации, напрямую оцениваемыми через ветки, но, по моему опыту, это слишком быстро становится слишком сложным для отслеживания.

• сотрудничество: это не зарезервировано для DVCS. (VCS предлагают их тоже). Обратите внимание, что для некоторых форматов (Word Document) их внутренняя версия может быть более эффективной.

Answer 3

Одна большая проблема с DVCS для научного программирования - это двоичные данные. Часто бывает, что научное программирование требует ввода / вывода гигантских файлов, и это очень быстро убивает производительность на всех известных мне DVCS (bzr, hg, git). Это одна из областей, где SVN сейчас намного лучше.

Я думаю, что DVCS может быть весьма полезным и для бумаг, но это означает, что ваш соавтор также знает DVCS.