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

Ответ 1

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

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

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

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

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

Ответ 2

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

• Обновить представление
• Внесите некоторые изменения.
• Проверьте свой код
• Обновить снова
• Разрешить конфликты слияния, если необходимо
• Фиксировать

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

Ответ 5

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

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

Ответ 6

Если они в основном учащиеся, одна точка продажи - это то, что здесь, в "реальном мире", многие люди очень серьезно относятся к версии.

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

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

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

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

Ответ 11

Попробуйте this. Я нашел его в поиске SVN для чайников, и он был описан как "SVN для чайников", руководство, которое может понять ваша бабушка: D

Ответ 12

Вот достойный SVN "cheatsheet", который описывает основное использование: http://abbeyworkshop.com/howto/misc/svn01/

Ответ 13

K сделайте своих друзей прочитайте это. Следующее изучение cli в первую очередь по нескольким проектам домашних животных очень сильно разъясняет это. Мой первый выход на подзаголовок заставил меня ненавидеть затмение. Частично потому, что я никогда раньше не использовал подрывную деятельность.

• проверка = получить локальную копию код, который находится в репозитории.
• Update = гарантирует, что ваша локальная копия обновляется с главной копией. aka сервер.
• commit = добавить свои изменения в главная копия
• merge = вы плюс кто-то еще когда вы проверили. слияние позволяет вам поддерживать ОБО наборы изменений через контролируемое редактирование.

Слияние - это аккуратная функция, но сначала немного сложная задача.

Ответ 14

Я бы предложил им прочитать, по крайней мере, основные части http://svnbook.red-bean.com/en/1.5/index.html, он хорошо написан с каким-то юмором. Он охватывает инструменты командной строки, но понятия одинаковы независимо от того, какой интерфейс вы используете (т.е. TortoiseSVN или Subclipse).

Ответ 15

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

Я никогда не видел смысла, пока не прочитаю эту маленькую книжку, попробуйте сделать их прочитанными как минимум на первых 20 страницах. Там хорошая аналогия между подрывной деятельностью и клавишей "отменить" любого редактора, которая может убедить их в ее использовании (она работала со мной:))

Ответ 16

Отправьте их по адресу:

• http://svnbook.red-bean.com/
• http://www.ericsink.com/scm/source_control.html

Имейте в виду, что они будут унижены как полные и полные дураки всеми, кто использует половину достойной системы управления исходным кодом (т.е. не VSS).

Ответ 17

Сначала вам нужно действительно продать их по концепциям управления версиями, чтобы они понимали, как работает svn.

Несколько вещей, которые нужно попробовать:

• Создание хранилища песочниц для обучения и экспериментов
• Попробуйте организовать несколько тренингов/семинаров. Если вы не уверены в том, что работаете сами, попробуйте поговорить с локальной группой пользователей Linux, чтобы узнать, знают ли они того, кто может помочь.
• Документируйте процесс разработки, включая общие сценарии использования subversion.

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

В вашей конкретной проблеме с фиксацией .project файлов вы можете либо установить свойство svn: ignore в свойстве, либо вы можете установить значение глобального игнорирования в каждом конфигурационном файле subversion для пользователей.

Ответ 18

Возможно, вы захотите создать псевдонимы для наиболее опасных команд (я думаю, в основном, о возврате), которые требуют явного подтверждения перед вызовом команды svn.

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

Ответ 19

Они всегда могут попробовать "бедный человек CVS": пусть они делают ZIP своего кода за мгновение до того, как они проведут чек или что-нибудь, и сохраните их пронумерованными где-то на своих жестких дисках.

В конце концов, у них будет куча файлов вроде:

• MyProject01.zip
• MyProject02.zip
• (и т.д.)

Это даст им ум, что их "работа" не будет "разрушена", если они сделают что-то глупое и будут достаточно громоздкими, чтобы заставить их научиться правильно использовать SVN (давайте, это не это сложно!).

Я лично нашел, что этот подход для бедного человека намного превосходит Visual SourceSafe: у бывшего работодателя я был вынужден использовать это чудовище... после того, как второй раз репозиторий полностью сломался, они поблагодарили меня за это: D

Ответ 20

Если вы разрабатываете в машинах Windows, попробуйте использовать TortoiseSVN в качестве вашего клиента подрывной деятельности. Интерфейс действительно замечательный. Я помогу им потерять контроль над версиями.

Ответ 21

Все о уверенности в использовании чего-то нового и о понимании того, что они используют. Когда вы его используете, счастливы, что это работает, "несогласие" исчезает.

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

Дайте им книгу svn и ссылки на TortoiseSVN, чтобы прочитать ее, когда у них есть обзор.

Затем попробуйте ручную мастерскую с репозиторией песочницы.

Затем будет доступно помощь в течение недели или около того, пока они будут использовать ее на самом деле.

этот подход работает для всего, а не только SVN.