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

Ответ 1

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

Конкретно, у меня есть одна папка в моей файловой системе под названием "FsCheck". В этом случае у меня есть один репозиторий и, следовательно, папка, называемая main. Как правило, у меня есть несколько папок рядом с тем, где я работаю над определенными функциями или исправлениями ошибок или что-то еще, скажем, об ошибках-исключениях и безупречной проверке и исправлении-userFoo. Они создаются с использованием hg-клона.

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

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

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

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

Вкратце:

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

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

Я использую 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 и т.д.

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

Но, возможно, вы извлечете что-то из question, который я поставил ранее.

Ответ 7

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

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

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

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

Кроме того, "стоимость установки" с меркурием довольно низкая. Вы читаете учебник, устанавливаете его, говорите "hg init" и продолжаете работать. Больше никаких ошибок, если что-то принадлежит вашему священному серверу SVN, куда его поставить и так далее. Меркурийное "трение" немного ниже SVN.

Ответ 8

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

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

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

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

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

Ответ 9

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

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

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

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

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

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

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

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

Ответ 13

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

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

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