Используете ли вы распределенный контроль версий? - PullRequest
37 голосов
/ 26 августа 2008

Я хотел бы услышать от людей, которые используют распределенный контроль версий (он же распределенный контроль версий, децентрализованный контроль версий) и как они его находят. Что вы используете, Mercurial, Darcs, Git, Bazaar? Вы все еще используете это? Если в прошлом вы использовали клиент-серверные rcs, вы находите это лучше, хуже или просто другим? Что ты можешь сказать мне, что заставит меня запрыгнуть на подножку? Или спрыгните в этом отношении, мне было бы интересно услышать от людей с отрицательным опытом также.

В настоящее время я смотрю на замену нашей текущей системы контроля версий (Subversion), которая является стимулом для этого вопроса.

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

Если вы не уверены, что такое распределенное управление версиями, вот пара статей:

Введение в управление распределенной версией

Запись в Википедии

Ответы [ 18 ]

1 голос
/ 27 августа 2008

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

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

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

Примечание. Я использовал его только в Linux, и в основном из командной строки, хотя он предназначен для хорошей работы на других платформах, имеет графический интерфейс пользователя, такой как TortoiseBZR , и выполняется большая работа при интеграции с IDE и т. п.

1 голос
/ 26 августа 2008

Я большой сторонник централизованного управления источниками по многим причинам, но я попробовал BitKeeper на проекте вкратце. Возможно, после многих лет использования централизованной модели в том или ином формате (Perforce, Subversion, CVS) я просто обнаружил, что управление распределенным исходным кодом трудно использовать.

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

1 голос
/ 26 августа 2008

Использование Subversion с SourceForge и другими серверами через несколько различных соединений с командами среднего размера, и это работает очень хорошо.

1 голос
/ 10 апреля 2009

Я играю с Mercurial для моих домашних проектов. Пока что мне нравится в этом то, что я могу иметь несколько репозиториев. Если я возьму свой ноутбук в салон, у меня все равно будет контроль версий, в отличие от того, когда я запускал CVS дома. Разветвление так же просто, как hg clone и работа с клоном.

0 голосов
/ 14 апреля 2009

Мы используем распределенный контроль версий ( Plastic SCM ) как для многосайтовых, так и для отключенных сценариев.

1- Мультисайт: если у вас есть удаленные группы, иногда вы не можете полагаться на интернет-соединение или оно недостаточно быстрое и замедляет работу разработчиков. Тогда наличие независимого сервера, который может синхронизировать данные назад (Plastic дублирует ветви назад и вперед), очень полезно и ускоряет процесс. Вероятно, это один из наиболее распространенных сценариев для компаний, поскольку большинство из них по-прежнему озабочены «полностью распределенными» практиками, когда у каждого разработчика есть свой реплицированный репозиторий.

2- Отключено (или действительно распределено, если вы предпочитаете): у каждого разработчика есть свой собственный репозиторий, который реплицируется взад и вперед с его коллегами или центральным местоположением. Очень удобно идти к клиенту или просто идти домой со своим ноутбуком и по-прежнему иметь возможность переключать филиалы, оформлять заказы и проверять код, просматривать историю, запускать аннотации и т. Д. Без необходимости доступа к удаленному «центральному» сервер. Затем, когда вы возвращаетесь в офис, вы просто копируете свои изменения (обычно ветки) в несколько кликов.

0 голосов
/ 26 августа 2008

Использование Subversion

Subversion не распространяется, поэтому я думаю, что мне нужна ссылка на Википедию на тот случай, если люди не уверены, о чем я говорю:)

0 голосов
/ 10 апреля 2009

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

Мост git-svn немного шаткий, потому что при регистрации в SVN он переписывает все коммиты, чтобы добавить свой комментарий git-svn-id. Это разрушает приятную историю слияний между моим коллегой и репо. Я предсказываю, что мы бы вообще не использовали центральный репозиторий, если бы каждый член команды использовал Git.

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

0 голосов
/ 27 октября 2008

Я использовал darcs 2.1.0 и отлично подходит для моих проектов. Легко использовать. Люблю вишню, собирая изменения.

...