Как вы комбинируете "Revision Control" с "Workflow" для R?

Ответ 1

Мой рабочий процесс не отличается от Бернда. Обычно у меня есть основной каталог, где я помещаю все мои файлы *.R. Как только у меня есть более 5 строк в текстовом файле, я запускаю управление версиями, в моем случае git. Большая часть моей работы не в контексте команды, означающая, что я единственный, кто меняет свой код. Как только я делаю существенное изменение (да, это субъективно), я делаю чек. Я согласен с Dirk, что этот процесс ортогонален процессу работы.

Я использую Eclipse + StatET, и хотя в Eclipse есть плагин для git (EGit и, возможно, другие), я не используйте его. Я в Windows и просто использую git -gui для Windows. Здесь несколько дополнительных опций.

Там много места для личных особенностей в управлении версиями, но я рекомендую этот совет в качестве лучшей практики: если вы сообщаете результаты другим (например, статья журнала, ваша команда, руководство в вашей фирме) ВСЕГДА выполните проверку контроля версий прямо перед запуском результатов, которые выходят другим. Неизменно 3 месяца спустя кто-то посмотрит ваши результаты и задаст какой-то вопрос о коде, который вы не можете ответить, если вы не знаете ТОЧНОЕ состояние кода при создании этих результатов. Поэтому сделайте это практикой и добавьте комментарии: "это версия кода, который я использовал для финансовых отчетов за четвертый квартал", или что бы вы ни делали.

Также имейте в виду, что контроль версий не заменяет хороший план резервного копирования. Мой девиз: "3 копии. 2 географические точки.

EDIT (24 февраля 2010 г.): Джоэл Спольский, один из основателей Stack Overflow, только что выпустил очень визуальный и очень прохладное введение в Mercurial. Только это руководство может быть основанием для принятия Mercurial, если вы еще не выбрали систему контроля версий. Я думаю, что когда дело доходит до git против Mercurial, самым важным советом является его выбор и использование. Возможно, используйте то, что используют ваши друзья/коллеги, или используйте тот, у кого есть лучший учебник. Но просто используйте его уже!;)

Ответ 2

Вместо того, чтобы сосредоточиться на контроле версий, в частности, похоже, что вы действительно задаете больший вопрос о том, как статистический анализ сравнивается с разработкой программного обеспечения. Это интересный вопрос. Вот несколько мыслей:

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

Тем не менее, я думаю, что представление о том, что статистический анализ является чисто исследовательским, без цели, потенциально проблематично. Это может привести к тому, что вы на 5 шагов после моментов эврики и не можете вернуться к нему. Всегда есть какая-то цель, даже если сама цель меняется. Более того, если нет цели, как вы узнаете, когда достигнете конца?

Один из подходов состоит в том, чтобы начать с одного R файла при запуске проекта (или набора файлов, например, в примерах Джоша и Бернда) и постепенно добавлять к нему (чтобы он увеличивался в размере), когда вы делаете открытия, Это также особенно актуально, когда у вас есть данные, которые необходимо сохранить в рамках анализа. Этот файл должен регулярно контролироваться версиями, чтобы вы всегда могли шагнуть назад, если вы совершаете ошибки (позволяя увеличивать прирост). Системы управления версиями чрезвычайно полезны в развитии не только потому, что они гарантируют, что вы не потеряете вещи, но также потому, что они предоставляют вам график. И пометьте свои чеки, чтобы вы знали, что в них с первого взгляда, и обратите внимание на основные этапы. Я люблю JD, чтобы проверить, прежде чем отправить что-то.

Как только вы достигли своего окончательного набора выводов, часто лучше всего создать окончательную версию вашего файла, которая суммирует ваш анализ от начала до конца. Вы даже можете подумать о том, чтобы положить это в документ Sweave, чтобы он был полностью автономным и грамотным.

Вы также должны серьезно подумать о том, что делают окружающие. Ничто не заставляет меня съеживаться больше, чем видеть людей, изобретающих колесо, особенно когда это означает дополнительную работу для группы в целом, чтобы интегрироваться с ней.

Ваши решения о том, какая система управления версиями использовать, какая IDE и т.д. (проблемы реализации) в конечном счете крайне низки на столбце тотема в отношении общего управления проектами. Просто используйте любой из них правильно, и вы уже на 95% оттуда, и различия между ними малы по сравнению с альтернативой использования ничего.

Наконец, если вы используете что-то вроде github, google code или R-forge, вы заметите то, что у всех есть общее: набор инструментов помимо системы управления версиями. А именно, вам следует рассмотреть возможность использования таких вещей, как система отслеживания проблем и вики, для документирования прогресса и регистрации открытых проблем/задач. Чем более организован вы с вашим анализом, тем больше вероятность успеха.

Ответ 3

Я использую git для управления версиями. Моя типичная структура каталогов (например, для статей) выглядит следующим образом.

.
..
.git
README
README.html
ana
dat
doc
org

Большинство каталогов/файлов (ana, doc, org) находятся под контролем версий. Разумеется, большие двоичные наборы данных исключаются из контроля версий (через .gitignore). README является файлом org-mode Emacs.

Ответ 4

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

• Резервные копии. Если что-то случайно удалено или капризы судьбы жарят ваш жесткий диск, ваша работа может быть восстановлена ​​из репозитория. С распределенным контролем версий ничего, кроме апокалипсиса, может привести к тому, что вы потеряете работу - в этом случае у вас, вероятно, будут все равно беспокоиться о любом случае.

• Мать всех кнопок отмены. Был ли анализ лучше, чем час назад? день назад? неделю назад? Управление версиями предоставляет кнопку перемотки, которая позволяет вам вернуться назад.

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

Другая сторона систем управления версиями заключается в том, что они способствуют совместным усилиям, позволяя людям экспериментировать с изолированной копией или "ветвью" материала проекта, а затем "слить" любые положительные изменения обратно в главную копию. Он также предоставляет средства для участников проекта следить за тем, какие изменения повлияли на строки каких файлов.

В качестве примера, я держу всю свою курсовую работу в колледже под управлением версиями в репозитории Subversion. Я единственный, кто работает в этом репозитории, поэтому я никогда не разделяю и не объединяю источник - я просто фиксирую и иногда перематываю. Возможность перемотки моей работы снижает риск попыток какого-то нового анализа - я просто делаю это. Если через два часа похоже, что это была не такая хорошая идея, я просто возвращаю файлы проекта и пытаюсь что-то другое.

В отличие от этого, большинство моих курсов/программ, не связанных с курсом, размещаются под git. В такой настройке я часто хочу экспериментировать на ветке, имея доступную стабильную копию. Я использую git, а не Subversion в этих ситуациях, потому что git делает ветвление и объединяет легкую задачу.

Важным моментом является то, что в обоих случаях структура моего репозитория и используемого рабочего процесса не используется моей системой контроля версий - они решены мной. Единственное влияние, которое имеет контроль над версиями на мой рабочий процесс, это то, что он освобождает меня от беспокойства о попытке чего-то нового, решив, что мне это не нравится, и затем должен отменить все изменения, чтобы вернуться туда, где я начал. Поскольку я использую контроль версий, я могу следовать совету Йоги Берры:

Когда вы придете к развилке на дороге, возьмите ее.

Потому что я всегда могу вернуться и принять его другим способом.

Ответ 5

Я сам использую git. Локальные репозитории, хранящиеся в том же каталоге, что и проект R. Таким образом, если я удалю проект по дороге, репозиторий пойдет с ним; Я могу работать в автономном режиме; и у меня нет проблем IRB, FERPA, HIPPA.

Если мне нужна дополнительная поддержка резервного копирования, я могу git в удаленный (защищенный!) репозиторий.

-Wil