Как заставить моих коллег не презирать SVN?

Question

Многие из моих коллег используют SVN в группах по 1-5 человек, частично работающих над конкретным проектом. Половина из них - неопытные студенты. На самом деле, мы не являемся настоящими разработчиками программного обеспечения с многолетним опытом. Большинство из них используют Eclipse и subclipse для чтения и записи своих материалов в репозитории SVN.

Некоторые из них имеют проблемы с разницей:

• извлечение (перепутано с обновлением и слиянием)
• коммит (путается с обновлением)
• обновление (перепутано с коммитом и проверкой)
• слияние (труднее всего. Что такое слияние? Нужно ли сливать мой код «в SVN»?)

Они боятся, что SVN может убить их работу (они не называют это рабочей веткой), если нажмут не ту кнопку.

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

В общем, говорят: Я бы хотел работать без SVN, мне это не нравится. Это слишком сложно.

Есть ли такой проект электронного обучения, как "SVN для детей"? Как я могу сделать их как контроль версий?

Answer 1

По моему опыту, одна из главных причин, почему так много людей "боятся" или не любят контроль версий, заключается в том, что они не понимают основополагающих концепций и того, как работает система . Это, к сожалению, верно и для многих опытных разработчиков. Я знаю людей, которые годами использовали CVS и Subversion, но они никогда не создают веток или тегов, потому что не понимают, как они работают, и поэтому считают их «сложными» или «ненужными».

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

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

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

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

Answer 2

Во-первых, вам нужно принять «программно-независимый» подход к рассмотрению этой проблемы. Не заставляйте их читать книгу «Red Bean» или рассказывайте обо всех изящных командах SVN. Вместо этого вы должны начать с изучения правильного рабочего процесса с контролем версий. В двух словах, это означает:

1. Обновите ваш взгляд
2. Внести некоторые изменения
3. Проверьте свой код
4. Обновите снова
5. Решать конфликты слияния, если необходимо
6. Commit

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

Ключ к успешному внедрению SCM имеет два аспекта; Во-первых, нужно, чтобы люди привыкли работать с программным обеспечением, делая обычные, безболезненные вещи (например, обновление / фиксация). Если вы этого не сделаете, разработчики будут стараться избегать использования SCM, пока вы не побеспокоите их об этом и не спросите, почему они не зафиксировали какой-либо код в течение двух недель. Во-вторых, вам необходимо научить людей преодолевать распространенные болезненные сценарии, которые могут привести к потере работы.

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

• Что будет означать .r1, .r2, .mine и исходный файл после конфликта
• Показать, как графически разрешить конфликты
• Теперь перекомпилируйте и снова протестируйте программное обеспечение, чтобы убедиться, что
• Сделайте резервную копию файла .mine, опять же, просто чтобы убедиться,
• Затем совершить

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

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

Answer 3

Простая «шпаргалка» по необходимым процедурам, приведенная пошагово, является наилучшим способом. У SVN есть некоторые подводные камни, которые не очевидны. Я был связан с новыми людьми, использующими его, и в некоторых случаях они действительно удаляли целые куски кода из текущей ревизии и т. Д. Конечно, вы всегда можете вернуться и получить от предыдущих версий, но SVN - это страшно и опасно для новых людей. Имейте это в виду и напишите очень простые, но четкие инструкции для необходимых операций!

Answer 4

«Как я могу сделать их похожими на контроль версий?»

Удалите их рабочие копии, и они быстро поймут, насколько полезным может быть программное обеспечение для контроля версий!

Серьезно, использование VCS - это то, что идет рука об руку с тем, чтобы быть зрелым разработчиком. Если вы не знаете, зачем вам Subversion, я бы не стал доверять им как разработчикам. Они могут иметь навыки программирования, но программирование - это только часть работы разработчика.

Я верю, что пока вы не потеряете код, вы действительно никогда не оцените VCS.

Answer 5

• неограниченное количество отмен - не нужно беспокоиться о потерянных изменениях
• резервное копирование, больше не ваша ответственность
• Функциональность 'машины времени' - как выглядел код в прошлую пятницу вечером?
• сотрудничество
• центральная, "официальная" версия исходного кода облегчает сборку релизов
• сравнение: кто-то осмелился прикоснуться к вашему коду, что именно он изменил?
• маркировка: помечайте стабильные версии, которые готовы к демонстрации, вы можете продолжить разработку в базе кода после

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

Answer 6

Если они в основном студенты, то одно замечание в том, что здесь, в «реальном мире», многие люди очень серьезно относятся к версионированию.

Если они боятся что-то удалить, продемонстрируйте удаление какого-либо важного файла и продемонстрируйте способность восстановить удаленные файлы .

Или им может понравиться другой вид управления версиями, такой как git или mercurial.

Answer 7

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

Answer 8

Дайте им краткую беседу о SVN. расскажите им, что такое преимущества и как их использовать.

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

Answer 9

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

1. Каждый разработчик создает ветку из основного ствола, прежде чем начинать кодировать;
2. Разработчик реализует функцию в своей собственной ветке и выполняет коммит (обновление не требуется, поскольку он является единственным разработчиком в своей ветке);
3. Пара более опытных разработчиков просматривает код, тестирует и объединяет ревизии веток с основной веткой;
4. промыть и повторить

Новые функции Subversion 1.5 действительно хороши для такого рода рабочих процессов.

Answer 10

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

После этого они узнают, о чем речь.