DVCS полезен для одного разработчика? - PullRequest
16 голосов
/ 07 октября 2008

Или более подходящим является обычный клиент-серверный VCS? В настоящее время я использую TortoiseSVN, но мне интересна DVCS, но я не уверен, стоит ли даже пытаться использовать что-то подобное соло.

Ответы [ 6 ]

15 голосов
/ 07 октября 2008

Поскольку вы все еще можете передавать на другую машину, на которой также работает Git / Mercurial / Bzr / etc, у вас все еще есть безопасность резервного копирования на нескольких компьютерах, которая, надеюсь, будет в любом случае. Однако, если вы когда-либо пишете код во время путешествий, наличие полного доступа к репозиторию может быть огромным плюсом, а затем просто выполните повторную синхронизацию с вашим сервером, когда у вас снова будет сетевое соединение / вернитесь домой / и т.д.

9 голосов
/ 07 октября 2008

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

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

5 голосов
/ 07 октября 2008

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

3 голосов
/ 16 августа 2009

Да. Есть две основные причины, по которым я переключился на DVCS (Git и Mercurial) для своих собственных хобби-проектов. Во-первых, это проблема хранения резервных копий , а во-вторых, я много путешествую и использую несколько географически отдельных компьютеров .

Быстрое и простое резервное копирование

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

Работа в разных местах или на компьютерах

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

Простое разветвление / слияние

Не секрет, что DVCS обрабатывает ветвления / слияния довольно автоматически. Конфликты слияний случаются, но даже без таковых в централизованных инструментах контроля версий, например Subversion не очень помогает в слиянии даже в простых сценариях. Хотя я не использую эту функцию все чаще для личных проектов, есть некоторые разработчики, которые делают.

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

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

Я настоятельно рекомендую пойти с распределенным. На Windows я выбрал Mercurial и был очень доволен этим.

Большие плюсы:

  • Локальные коммиты бывают быстрыми, могут фиксироваться часто (Test, Code, Refactor, Commit)
  • Ветвление просто
  • Вы можете совершить, где бы вы ни были.
  • Простое перемещение файлов (нет больше беспорядка, как в случае с SVN)
  • Просто проще. Одно программное обеспечение делает все это (включая задачи администратора)
  • Файловая система чище. Нет больше .svn везде, только одна папка
  • Список игнорируемых файлов - это просто еще один файл в хранилище, который автоматически копируется в каждый клон. Проще содержать в чистоте, чем снова SVN.
  • Bitbucket.com хорош и дает один бесплатный приватный репозиторий

Минусы:

  • (для некоторых) инструментов с графическим интерфейсом нет
  • Вам, вероятно, понадобится SVN для подключения к различным исходным репозиториям. Например. нужно использовать две системы.
1 голос
/ 07 октября 2008

Для одного разработчика подойдет любая VCS. Я бы выбрал тот, который прост в настройке и практически не требует настройки. Мне лично нравится Monotone . Это был один из первых, и я до сих пор считаю его одним из лучших.

На самом деле, самое забавное, что я когда-либо получал, это когда использовал darcs , но он написан на довольно уродливом языке (Haskell), и на самом деле было довольно сложно собрать его на Mac OS X из исходного кода .

Говорят, что Git - хорошая система, но мне не нравится, что она состоит из нескольких двоичных файлов, скриптов и так далее. Что мне действительно нравится в таких системах, как darcs и Monotone, так это наличие одного двоичного файла ... и все. Никакой путаницы двоичных файлов, никаких скриптов на том или ином языке, на двоичном, и все это делает.

...