Стоит ли смотреть на системы контроля версий помимо Subversion?

Question

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

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

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

Я слышал о GIT и провел некоторое исследование. Я планирую попробовать, но пока я возиться с этим, есть ли другие системы контроля версий, которые считаются «отраслевыми стандартами», и они работают лучше, чем SVN?

Answer 1

Git, Mercurial и Bazaar - это распределенные системы управления, основанные на идее, что вы не всегда подключены к сети и что не требуется единой центральной версии хранилища.

Если вы выполняете много самостоятельной работы, иногда называемой «режимом самолета», например, когда вы летите на самолете и не можете совершить коммит, посмотрите на Bazaar. Мне было легче акклиматизироваться, чем Git или Mercurial.

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

Также обратите внимание на значение , сохраняющее ваш домашний каталог в Subversion .

Answer 2

Mercurial

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

• Mercurial может масштабироваться от одной группы до огромной, то есть OpenJDK, без особой головной боли.
• Mercurial быстрый, возможно, не такой быстрый, как GIT, но он все еще очень быстрый
• Mercurial Queues - это фантастический способ управления патчами. На скорости смазанного освещения.
• Может работать на разных ОС, совместимость отличная, так как основана на python.
• кривая обучения ниже, чем в GIT, после прочтения нескольких документов вы получите базовый набор вещей (http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/)
• hg позволяет (как и многие DSVC) взаимодействовать с корпоративным элементом управления исходным кодом SVN с помощью hg-svn и hgsubversion, который является замечательным расширением с разрешениями и извлечениями, но еще не поддерживает функцию принудительного нажатия или фиксации
• Вы также можете настроить HTTP-сервер для запуска push и pull через SSH
• также имеет действительно изящную возможность собраться с вашими друзьями по кодированию и просто запустить HTTP-сервер, запустив его через localhost, и ваши товарищи могут толкать и тянуть, пока вы выполняете кодовый спринт.
• Вы также можете увидеть текущее состояние проекта через эту страницу HTTP.
• наконец, посмотрите здесь краткое описание простых команд (http://edong.net/2008v1/docs/dongwoo-Hg-PDF.pdf)

Гит

• попробовал, его поддержка SVN лучше, чем Mercurial. но поскольку hgsubversion находится на подъеме и становится конкурентом за git svn.

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

BZR

• никогда не пробовал

Я не оглядывался назад, так как начал с HG

Answer 3

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

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

Answer 4

Я бы лично остался в Subversion. С профессиональной точки зрения, я видел, что гораздо больше рабочих мест спрашивают (и знают), что такое Subversion по сравнению с GIT. Также существует множество инструментов с открытым исходным кодом и бесплатных программ, созданных вокруг Subversion, не говоря уже об огромном сообществе Subversion.

Контроль исходного кода не всегда является самым последним и лучшим, но чаще всего о том, что проверено и соответствует действительности.

Answer 5

Вот 3 причины перейти на git из Subversion (из MarkMcB):

• Бесконечные, простые, не основанные на файловой системе, локальные ветви
• Скрытая временная работа
• Сотрудничество до публичных коммитов

(Прочитайте связанную статью для полного объяснения и прямого сравнения того, как сделать три вещи и в git и в Subversion.)

Answer 6

Я тоже лично остался бы в Subversion, Есть что-нибудь лучше?

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

Answer 7

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

Единственное, по чему я серьезно скучаю, это TortoiseSVN; есть рабочий (TortoiseHg), который довольно хорош, но просто не тот ...

В любом случае, создать репозиторий Mercurial из SVN тривиально просто ... попробуйте и посмотрите, подходит ли вам это или нет.

Answer 8

Правило №. 1: «Никогда не меняйте работающую систему» ​​

Кроме того, поскольку существует множество блестящих новых решений (для проблем, которых у вас нет, поскольку вы работаете в одиночку), вы должны учитывать стоимость перехода на новую VCS: Импорт subversion в Mercurial / git - непростая задача

нет инструмента (AFAIK), который импортирует репозитории SVN с использованием dumpformat. Поэтому, если вы не используете dumpformat, вы будете использовать все ветки / теги из svn и добавлять их в git / BZR / Mercurial вручную / через скрипт

Так что я не знаю, насколько велики ваши репозитории (мои репо варьируются от 20 МБ до 24 ГБ), но потребуется длительное время , чтобы проверить весь репо и даже небольшие проекты с большим количеством тегов съедает много места на жестком диске .

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

Answer 9

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

Я попробовал SVN для работы соло, и кто-то порекомендовал мне Mercurial (hg). Теперь я делаю основные замечания по этому поводу. Это более дружелюбно, чем мерзавец в окнах. Теперь я думаю: «Почему SVN усложняет простую задачу, такую ​​как теги?». SVN не знает, что такое тег. Для SVN тег является копией. В Mercurial тег является псевдонимом для ревизии. Насколько это может быть сложно?

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

Хотя я ничего не знаю о серверах, которые поддерживают Mercurial для онлайн-версии вашего репо.

Answer 10

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