Переезд из SVN в ...?

Question

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

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

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

Все в значительной степени работают в среде Windows, используя tortoisesvn, и именно так они привыкли взаимодействовать с системой, но иногда они используют PuTTY для работы на одном из серверов Linux и знают, как выполнять командную строку. совершить.

Как с этим справиться, я видел некоторую работу, выполняемую для создания шлюзов между SVN и некоторыми DVCS, есть ли у кого-нибудь опыт настройки и работы в такой среде?

Как насчет полномасштабной миграции с SVN на DVCS?

Answer 1

Если ваша команда не может понять, как правильно использовать Subversion, я не знаю, как вы сможете заставить их понимать git. Тем более, что они думают «позволяет всем работать в одной рабочей копии», им будет трудно разобраться с распределенной системой контроля версий.

По моему опыту, чтобы использовать svn-git, вы должны знать, как использовать git И вы должны знать, как использовать svn. Я бы рекомендовал научить их правильно использовать SVN.

Answer 2

Есть ли причина, по которой вы не хотите просто хранить свой SVN-репозиторий и использовать его так, как SVN предназначен для использования?

Почему бы не сделать так, чтобы все регистрировались и сливались, использовали ветки и т. Д.? Зачем переключаться, если у вас есть настройки репозитория?

Answer 3

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

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

Answer 4

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

Ваша текущая система SVN будет вполне адекватной; Позвольте пользователям создавать ветки, если вам нужно сохранить хобот в чистоте. Архитектор может объединить их так, как ему нужно.

Теперь вы можете переместить DVCS, и для этого есть веские причины. Но если команда не привыкла использовать клиент-серверные rcs, это может оказаться проблематичным. И вы могли бы локально использовать git или hg, но это обходные пути к принципиально нарушенному использованию rcs. Сначала советую всем использовать svn.

Редактирование файлов в общей папке samba ?? Шутки в сторону?!

Answer 5

Ваша проблема не в самом SVN, а в неправильном его использовании.

Answer 6

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

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

Для пользователей svn также есть хороший ускоренный курс по синтаксису git, который вы можете использовать для ускорения работы вашей команды.

Answer 7

Как мог бы сказать Стив Йегге: TOOOOOLS

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

Они используют IDE? Если это так, найдите плагины для IDE, упрощающие использование svn. Таким образом, они могут щелкнуть правой кнопкой мыши файл или папку в среде IDE и зарегистрироваться. Если вам проще использовать управление исходным кодом для локальной копии, чем для прямого доступа к центральным файлам, у вас может быть шанс. Затем вы можете использовать TortoiseSVN для более сложных задач.

Некоторые ссылки на плагины SVN для популярных IDE, с которых можно начать:

• Visual Studio - АнхСВН и VisualSVN
• Eclipse - Subversive и Subclipse
• Netbeans - Subversion

И вот список плагинов IDE с веб-сайта Subversion.

Answer 8

рт.ст. тоже неплохо работает с Subversion - см. https://www.mercurial -scm.org / wiki / WorkingWithSubversion . Команда разработчиков ядра Python просто решила переключиться с Subversion на Mercurial (после длительного периода обсуждения и обсуждения, где также рассматривались git и bazaar); В неродственной разработке бесплатный хостинг code.google.com для проектов с открытым исходным кодом добавил поддержку hg в свою давнюю поддержку svn.

Answer 9

и git, и bazaar хорошо поддерживают svn. За последние несколько месяцев Infact Git-SVN немного повзрослел.

попробуйте git, потому что DVCS действительно хорош, и не так сложно, как вы говорите.