Как мне контролировать версии (вроде) несвязанных скриптов по одному и тому же пути?

Question

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

1. Как DVCS, он не требует сервера.
2. Если я хочу, я могу хранить частный репозиторий онлайн дляfree (bitbucket.org)
3. Казалось бы, использовать проще, чем Git.

Mercurial хорошо работает с версиями модулей PowerShell, поскольку каждый модуль содержится в своем собственном каталоге.Тем не менее, у меня есть несколько сценариев, которые не принадлежат модулю, но я все же хотел бы их версии.Эти сценарии находятся в каталоге «. \ Scripts», который добавляется в $env:PATH, поэтому я легко могу запустить их из командной строки.Поскольку эти сценарии на самом деле не связаны друг с другом, не имеет особого смысла создавать единый репозиторий для каталога Scripts.

Как мне создавать версии отдельных сценариев?

Я подумал о следующих параметрах:

• Создайте подкаталог для каждого скрипта / связанных скриптов.
• Используйте временные репозитории, пока скрипт не станет "стабильным", затем добавьтеСценарий к основному каталогу «Сценарии» и версия коллекции сценариев как один.Это уменьшит количество наборов изменений, введенных в репозиторий «Скрипты».

Существует ли инструмент, который лучше обрабатывает версионирование отдельных файлов?Есть ли лучший способ для контроля версий отдельных файлов с Mercurial?Есть другие идеи?

Answer 1

Группировка файлов по их функциональности должна основываться на

1) Имя.

2) Папка, в которой они находятся.

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

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

И не волнуйтесь, сколько "наборов изменений" в репо!

PS: Может показаться немного самоуверенным, но нет реального правильного или неправильного ответа на ваш вопрос.

Answer 2

Отойдите, расслабьтесь и спросите себя, является ли это преждевременной оптимизацией .Основное преимущество использования VCS заключается в том, что вам , а не нужно беспокоиться о том, чтобы начать с "идеального" решения.DVCS отслеживает историю изменений при переименованиях и перемещениях (используйте hg mv или попробуйте автоопределение с помощью hg addremove --similarity).

Эти сценарии находятся в каталоге ". \ Scripts", который добавляется в $ env: PATH, поэтому я легко могу запустить их из командной строки.Поскольку эти сценарии на самом деле не связаны друг с другом, не имеет смысла создавать единый репозиторий для каталога Scripts

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

• Использовать временные хранилища, пока скрипт не станет "стабильным" ...

«Временное» репо лишает цели наличия репо, то есть истории изменений.

Это уменьшит количество наборов изменений, введенных в репозиторий «Сценарии».

Как сказал @manojlds, нет причин беспокоиться о количестве наборов изменений.Нет.

Мой совет:

• Поместите свои экспериментальные сценарии в каталог, например ./Scripts/incubating/
• Когда сценарий созревает, поместите его в ./Scripts/ или ./Scripts/Foo/ или что-то еще; используйте hg mv, чтобы помочь Mercurial отслеживать перемещение / переименование
• • Или использовать hg addremove --similarity для автоматического обнаружения перемещений / переименований
• История изменений скрипта сохраняется, и вы можете реорганизовать свои каталоги скриптов по мере развития вашей коллекции

Answer 3

Я думаю, что у парней здесь есть несколько хороших идей, и они указали, что вы, возможно, слишком сосредоточены на этом. Для абсолютно беззаботного управления источниками см. Руководство Тома http://powertoe.wordpress.com/2010/12/12/why-every-it-pro-should-use-mercurial-for-source-control-with-their-powershell-scripts/

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

1. в плохой день и переписал сценарий, чтобы он не делал того, чего вы хотите, и вы не можете вспомнить, как его вернуть!

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

Таким образом, наличие всех сценариев в одном репо на самом деле не проблема.

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