Почему распределенное управление исходным кодом считают более трудным?
Как отметил Марк Роттвил , я пытался подключиться к экземпляру LocalDB с помощью JDBC, что казалось невозможным. (ref: здесь )
Однако, я установил jTDS и добавил в мой путь к классу, изменил строку подключения на
jdbc:jtds:sqlserver://./TestBazyDanych;instance=LOCALDB#EB7165FD;namedPipe=true
, создайте соединение с помощью этого Строка подключения, имя пользователя и пароль, и это работает. Номер трубы экземпляра был взят из строки cmd через
sqllocaldb i MSSQLLocalDB
9 ответов
Распределенная система управления версиями является Очень Хорошей Вещью (TM), но я нахожу основной барьер для принятия, являющегося обучающими пользователями на новых возможностях, которые дает новый SCM.
Это вместе с часто тусклой суммой инструментов UI (наполовину законченные реализации черепахи и т.д.), приносит пустой взгляд к глазу многих коллег кто давно foreswore командная строка ради хорошего инструмента UI.
Кроме того, с инструментами как CVS я нахожу, что люди ненавидят ветвление и слияние, потому что они действительно действительно не хотят застревать весь день, делая три пути слияния, часто не действительно уверенные, который был бы правильным слиянием, чтобы сделать.
Моя точка: Начните путем сообщения людям, что они получают (не только, "эй наблюдают эту новую прохладную игрушку"), и подготовьте их к тому, что использование командной строки ЯВЛЯЕТСЯ способом пойти и что частое постоянное время, переходя является хорошей вещью.
Много систем такой как подвижные прибывают с полной системой очереди патча, означая, что с Непрерывной точки зрения Интеграции Вы знаете, что то независимо от того, что входит в производство, было утверждено QA. Материал как это трудно сделать правильно с CVS или SVN.
С Подвижными людьми имел бы частные репозитории для их текущей работы, и все разработчики совместно используют дерево разработчика на сервере. Системные мониторы CI дерево разработчика и получения по запросу все изменения, сборки, и выполняют unittests. Если все передает его, распространяет изменения в дереве Тестирования от того, где поставляемый компонент создается для людей QA. Каждый changeset, который добавляется, получает маркер. Когда QA считает функцию, чтобы быть завершенным, они аннотируют дерево Тестирования этим маркером, и связанные changesets затем автоматически распространены к Производственному дереву.
Используя этот подход Вы ничего никогда не будете фиксировать вручную производственному ответвлению или ответвлению тестирования. Скорее состояние кода и знак прочь от QA определяют контент Вашего производственного ответвления,
Я полагаю, что концептуально более просто думать о централизованном репозитории, где каждый разработчик фиксирует свою работу по сравнению с несколькими копиями всего репозитория, ни один из которого не представляет 'истину'. Так как большинство разработчиков знакомо с понятием клиент-серверной модели и базы данных бэкенда, это - естественное понятие.
Конечно, самая сила распределенных систем управления исходным кодом состоит в том, что они не должны придерживаться этой модели, но для вновь прибывшего, кажется легче схватить.
При использовании управления версиями только для себя SVN, вероятно, более тверд, так как установка более трудна. Если Вы однако хотите работать с несколькими разработчиками по сети, серверное управление имеет преимущества:
- У Вас есть одно центральное место, которое всегда имеет официальный современный источник, будучи сервером SVN
- Так как все всегда объединяют его изменения против центрального сервера, существует намного меньше коллизий и намного меньше ручной фиксации коллизий
- Вы имеете центральный контроль над источником
- У Вас есть официальное число пересмотра вместо хеша пересмотра, будучи тем же среди всех разработчиков и показа официального прогресса (это целое число, в отличие от хеша, который является просто цифровым отпечатком идентификационных данных, таким образом, Вы видите, какой код является более новым или более старым, только этим числом
Svn вызывает единственную строку работы. Можно или фиксировать, или Вы не можете. Имея подобные события, я не нахожу, что Hg или Git трудно используют, однако, я работаю над командой, кого, кажется, находит это кошмарным для использования их.
Целое понятие автоветвления, многосекционных головок, когда к и если не объединиться полностью уклоняется от них, не говоря уже о, они испытывают затруднения, освобождающиеся от "фиксации/контроля с $somecore" менталитет, который ведет для завершения беспорядка, когда они видят, что нажатия между 2 проверили копии.
(Имел проблему некоторое время, где кто-то неоднократно объединял 2 ответвления, которые, как предполагалось, не были объединены, потому что они не могли схватить понятие.)
Однако те же люди, кого испытывает затруднения из-за распределенного SCMS, заставили меня задавать этот вопрос
редактируйте/отмечайте Mercurials самое большое различие, которое я отметил по сравнению с мерзавцем, который делает подвижным тяжелее для использования для новичков, mercurials поведение по умолчанию для нажатия/получения по запросу, похож на выполнение нажатия мерзавца - всех / получение по запросу мерзавца - все, которые могут распространить частные ответвления и добавить много беспорядка (тем более, что, когда новое ответвление поднимается, подвижные замораживания в страхе и спрашивает Вас, как обработать его вместо того, чтобы просто продолжить ездить на грузовике), а также инструмент слияния/разрешения конфликтов по умолчанию на Mac, просто ударяющем один набор изменений вслепую.
Я думаю, что набор инструментов для SVN намного более широк, таким образом, Вы могли сесть и учить людей (TortoiseSVN, RapidSVN и т.д.), даже если бы у них не было большой концептуальной идеи того, как репозиторий работал. Также относительно легко разместить SVN для Вас (с trac, например), не будучи должен знать что-либо. Распределенные еще не имели этой поддержки, и я уверен, что мнения их изменятся, когда они сделают.
Я утверждал бы, что установка репозитория с DVCS практически легче, но концептуально тяжелее. В конце концов, с централизованным VCS пользователи не открывают свой собственный репозиторий, они просто создают учетную запись на Assembla или имеют repo, настроенный для них.
DVCS в настоящее время испытывает недостаток в хороших настольных клиентах. Несмотря на то, что говорит большинство людей, системы управления версиями может быть довольно трудно использовать правильно, таким образом, хороший настольный клиент может действительно помочь - и здесь TortoiseSVN выделяется.
Мы изо всех сил пытаемся сделать его максимально легким в Codice, но всегда немного более трудно объяснить, конечно, это зависит от аудитории.
Для проектов OSS и малочисленных команд, особенно люди, работающие над их ноутбуками и переезжающие сюда и там, работая дома, плоскость иногда, и так далее, это довольно легко. Но, каждый раз, когда Вы говорите с корпорациями/предприятиями, они приходят в восторг от его многоузловой роли, но не так очень о распределенном на первый взгляд. Все это зависит от того, есть ли у группы большинство опытных разработчиков или нет.
Это плохой маркетинг , все просто. Слишком много представлений DVCS сосредотачиваются на командной строке и говорят: «Вау, разве это не фантастика, вы можете выполнить слияние, просто набрав hg merge», совершенно не обращая внимания на тот факт, что многие люди (особенно в мире Windows) боятся командная строка. Да, Джоэл Спольски, я смотрю на ваш собственный hginit.com здесь - нам нужна версия TortoiseHg, пожалуйста!
Возможно, два года назад у них были плохие реализации графического интерфейса, но в последнее время они стремительно развиваются. TortoiseHg сейчас находится в версии 1.0, и хотя визуально в ней не особо выделяется, она довольно прочная, стабильная и простая в использовании. TortoiseGit также надежен и отлично справляется со всеми сложностями командной строки git.