Как мне использовать Mercurial в качестве разработчика-одиночки?

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

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

Должен ли я иметь несколько репозиториев? На моем компьютере разработчика уже каждую ночь создается резервная копия на моем Windows Home Server, поэтому не представляется важным иметь второй репозиторий в другом месте только для целей резервного копирования.

Стоит ли разветвляться каждый день? Или только около релизов? Или когда?

В целом, какие методы вы рекомендуете разработчику-одиночке, использующему Mercurial?

Какова ваша мотивация использования Mercurial? ИМО, для одного разработчика svn более чем достаточно.

yanchenko 24.02.2009 10:53

Вы должны маркировать, а не разветвлять новые выпуски. Я ответил ниже.

Tim Post 24.02.2009 10:58

@gsmd Некоторым из нас нравится делать коммиты в автономном режиме :) Мне нравится делать много небольших коммитов, а затем нажимать, сохраняя при этом упорядоченный набор патчей, удобный для людей, скачавших исходный код tgz. Я думаю, это вопрос предпочтений.

Tim Post 24.02.2009 10:59

@gmsd, зачем вам svn, если вы разработчик-одиночка? Затем вам нужно будет создать репозиторий svn. Я согласен, что Mercurial достаточно для одного разработчика.

Joshua Partogi 23.07.2009 13:55
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
62
4
6 079
13
Перейти к ответу Данный вопрос помечен как решенный

Ответы 13

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

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

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

Обычно они такие же, как если бы вы работали над любым программным проектом. Простое наличие или отсутствие контроля версий не подлежит обсуждению;)

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

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

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

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

Таким образом, вы можете исправить ошибки в основной ветке при создании новой функции в собственной ветке.

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

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

Удачи,
Рэнди Стегбауэр

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

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

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

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

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

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

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

Филиалы обычно используются для разделения разных «версий» проекта. Как уже упоминали некоторые люди, это может быть полезно в качестве индивидуального разработчика для опробования метода рефакторинга кода или тестирования другого подхода к конкретной проблеме. Если не получится, не нужно беспокоиться о том, куда откатиться, достаточно просто поджечь ветку. Если это сработало, вы снова объединяете ветку с основным репозиторием («ствол») и продолжаете.

Если вы дойдете до того момента, когда вы сделаете «релизы» кода, и вам нужно будет поддерживать старые версии, вы также захотите использовать ветки. Например, представьте, что вы выпускаете версию 1.0, и некоторые люди начинают ее использовать. Пока они его используют, вы в частном порядке продолжаете работать над следующим выпуском, возможно, 1.1, добавляя функции в свой основной репозиторий. Теперь кто-то обнаруживает ошибку в выпущенном коде 1.0, которую вам нужно исправить, но вы не можете просто исправить ее в магистрали и передать им этот код, потому что он не находится в состоянии, подлежащем выпуску. Здесь пригодится ветка 1.0. Вы можете исправить ошибку в ветке 1.0 и объединить исправление ошибки в ствол, так что ошибка будет исправлена ​​и там. Затем вы можете переупаковать 1.0 с исправлением ошибок и передать его своим пользователям, не пытаясь понять, как привести транк в состояние, при котором его можно будет опубликовать.

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

Для получения дополнительной информации я настоятельно рекомендую прочитать эту книгу: Распределенный контроль версий с Mercurial. Вам не обязательно углубляться в углубленные темы, но чтение хотя бы глав 1-5 и 8 даст вам хорошее введение в Mercurial и управление версиями в целом.

Я использую другую распределенную систему контроля версий, чем Mercurial, но сомневаюсь, что это имеет значение для этого.

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

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

Преимущество такого стиля работы в том, что если выяснится, что изменения, над которыми я работаю, - плохая идея, я легко могу отказаться. На самом деле отступать не от чего, поскольку изменения не были объединены.

Иногда я ленив и не создаю новую ветку для чего-то нового, что я разрабатываю. Неизменно оказывается, что это ошибка, когда мне нужно больше времени, чем я ожидал, чтобы закончить работу. Становится хуже, когда мне нужно сделать другое, не связанное с этим изменение посреди этого. Когда я следую стилю all-work-in-its-own-branch, несвязанное изменение может быть выполнено в его собственной ветке, объединено в ствол, а затем другая ветвь может объединить изменение из ствола, если это необходимо.

Я использую Mercurial ежедневно, см. здесь, я также помогаю в одной из немногих бесплатных услуг хостинга, поддерживающих Mercurial, ShareSource (я на странице кредитов). Я использую HG с тех пор, как Xen сбросил BitKeeper.

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

Мой типичный день с hg:

(See where I left off)
# hg status 

(See what I was doing with foo)
# hg diff -r tip src/foo/foo.c

(Finish one module, commit it)
# hg commit src/foo/foo.c

(Push changes)
# hg push

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

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

Конечно, да, я использую Git и SVN .. но не для личных проектов. Замечание о моем индексе репо (ссылка размещена), я переписал hgwebdir на PHP, потому что хотел легко изменить его внешний вид и вытащить RSS из каждого репо.

Короче говоря, для личного использования он вам ОЧЕНЬ удобен. Коммиты, теги и т. д. Просты ... избегайте веток, если они вам действительно не нужны.

Это руководство, которое я написал некоторое время назад, описывающее, как использовать Mercurial для управления веб-сайтом, оно может вас заинтересовать при настройке ключей, hgrc и т. д.

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

Ответ принят как подходящий

Я использую Mercurial для разработки FsCheck, фреймворка для модульного тестирования, размещенного в codeplex. В настоящее время я единственный разработчик, но иногда люди присылают мне патчи.

Конкретно у меня есть одна папка в моей файловой системе под названием «FsCheck». В этом случае у меня есть один репозиторий и, следовательно, папка с именем main. Обычно у меня есть несколько папок рядом с той, где я работаю над определенными функциями или исправлениями ошибок или чем-то еще, например, error-escapingexceptions и feat-statefulchecking и patch-userFoo. Они созданы с использованием hg clone.

Когда я заканчиваю с функцией или исправлением, я фиксирую все в этой папке и нажимаю на main. Возможно слияние в main. (hg commit, hg push, hg merge). Затем я удаляю папку (осторожно, используя hg status и hg outgoing, чтобы я не выбрасывал что-то полезное).

Я почти никогда не работаю в основном, кроме как прямо перед выпуском, где я делаю окончательную очистку (например, документацию). Перед выпуском я помечаю в основном номер выпуска (hg tag v0.5.1).

Codeplex использует svn в качестве источника управления. Я использую его только для хранения выпусков, для которых я использую локально проверенную рабочую копию SVN, в которую я копирую репозиторий Mercurial с помощью архива hg. Затем выполните фиксацию с помощью svn. Примитивный, но он работает (использование Mercurial в качестве «суперклиента» SVN в Windows, по моему мнению, пока не очень удобно для пользователя)

Мне еще не приходилось обслуживать предыдущие выпуски, но я бы сделал это, клонировав основной репозиторий из ревизии этого выпуска (это легко, поскольку я пометил его) и буду работать в этом отдельном репозитории. Обратное слияние с основным стволом будет таким же простым, как внесение изменений в основную ветку и слияние.

В итоге:

  • Одна папка для хранения всех репозиториев вашего проекта с именем вашего проекта
  • В этой папке одно основное хранилище и одно временное хранилище на «единицу работы» с описательным именем для единицы работы.

Это приятно, потому что ваши ветки и то, над чем вы работаете, интуитивно видно в файловой системе.

Почему вы удаляете папку после того, как толкаете ее вверх?

Jay Bazuzi 02.03.2009 03:13

Так что папки, которые я вижу, представляют то, над чем я сейчас работаю. Если бы я сохранил все репозитории, я бы потерял контроль. История видна из самого репозитория с помощью hg glog (я использую это для создания журналов изменений)

Kurt Schelfthout 02.03.2009 10:49

DVC, такие как Mercurial - а также Bazaar и Git - сделали многие вещи дешевыми, так что армия из одного человека может извлечь выгоду из расширенных возможностей.

  1. Вы можете быстро поэкспериментировать с "одноразовый" код, если вы поддерживаете дисциплина в продолжении работы ветки в актуальном состоянии или вне основной сети и синхронизируйте все свои дельты в DVC.

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

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

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

    б. Я установил CopSSH на свой WHS, и он работает прекрасно обеспечивая функциональность SSH / SFTP / SCP в окно Windows в ~ 5 МБ. до этого я был запуск Ubuntu Linux на Virtual Server 2005, чтобы предоставлять, среди прочих услуг, аналогичные функциональность. Вы можете подтолкнуть свой ртуть к поле WHS по ssh

Раньше я использовал CVS, Perforce, Subversion в качестве своей личной системы контроля версий, а около двух недель назад перешел на Mercurial :-) На работе мы используем MS Team System ...

Для меня самая заметная новинка - это легкий перенос между разными машинами. На работе у меня есть материалы в ртутном репо (с использованием hg в качестве суперклиента против командной системы). Я регулярно отправляю / забираю все изменения на / с моего ноутбука, поэтому у меня есть полная история на обеих машинах.

Дома тоже репо с ноута выталкиваю / вытаскиваю.

В результате я могу работать где угодно (домашний офис с мощным компьютером, в дороге с ноутбуком или на работе) и не беспокоиться о том, потеряю ли я изменения. Хорошо, иногда мне нужно объединить два изменения, но это редко повредит ... hg делает это довольно хорошо ИМХО.

Кроме того, «стоимость установки» с ртутью довольно низка. Вы читаете руководство, устанавливаете его, говорите «hg init» и продолжаете работать. Больше не нужно решать, принадлежит ли что-то вашему священному серверу SVN, куда это поместить и так далее. «Трение» Mercurial немного ниже, чем у SVN.

Я всегда использую Git или Mercurial, даже в одиночку.

Я разделяю репозитории, когда хочу сделать некоторые повторно используемые компоненты доступными для других проектов. Я настроил, что когда я фиксирую, он тоже нажимается автоматически (я делал с плагином Tortoise HG), потому что иногда я забывал нажимать, и при географическом перемещении мне нужен этот код, понимаете?

Итак, это мои советы.

Другие вопросы по теме