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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

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

В итоге:

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

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

Answer 2

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

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

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

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

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

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

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

Answer 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 и т. Д.

Answer 4

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

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

Answer 7

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

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

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

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

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

Answer 8

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

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

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

Answer 9

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

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

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

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

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

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

Answer 10

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