Упорядочивание сборки, когда использование распределило управление версиями
Из часто задаваемых вопросов -
Операции на Google Диске могут быть приостановлены, если количество файлов или подпапок в папке становится слишком большим. Если тысячи элементов непосредственно содержатся в папке «Мой диск» верхнего уровня, то установка диска, скорее всего, истечет. Повторные попытки могут в конечном итоге увенчаться успехом, поскольку неудачные попытки локально кэшируют частичное состояние до истечения времени ожидания. Если вы столкнулись с этой проблемой, попробуйте переместить файлы и папки, непосредственно содержащиеся в «Моем диске», в подпапки. Аналогичная проблема может возникнуть при чтении из других папок после successdrive.mount (). Доступ к элементам в любой папке, содержащей много элементов, может вызвать ошибки, такие как OSError: [Errno 5] Ошибка ввода / вывода (python 3) или IOError: [Errno 5] Ошибка ввода / вывода (python 2). Опять же, вы можете решить эту проблему, переместив непосредственно содержащиеся элементы в подпапки.
BLOCKQUOTE>
6 ответов
Я второй предложение использования git describe. При условии, что у Вас есть нормальная политика управления версиями, и Вы не делаете, любой сумасшедший материал с Вашим репозиторием, git describe всегда будет монотонным (по крайней мере, столь монотонный, как можно быть, когда история пересмотра является DAG вместо дерева), и уникальный.
Немного демонстрации:
git init
git commit --allow-empty -m'Commit One.'
git tag -a -m'Tag One.' 1.2.3
git describe # => 1.2.3
git commit --allow-empty -m'Commit Two.'
git describe # => 1.2.3-1-gaac161d
git commit --allow-empty -m'Commit Three.'
git describe # => 1.2.3-2-g462715d
git tag -a -m'Tag Two.' 2.0.0
git describe # => 2.0.0
вывод git describe состоит из следующих компонентов:
- новейший тег, достижимый от фиксации, Вы просите описывать
- количество фиксаций между фиксацией и тегом (если ненулевой)
- (сокращенный) идентификатор фиксации (если № 2 является ненулевым)
, #2 - то, что делает вывод монотонным, № 3 - то, что делает это уникальным. № 2 и № 3 опущены, когда фиксация тег, делая git describe также подходящий для производственных выпусков.
git tag может быть достаточно, для какого Вам нужно. Выберите формат тега, который все согласятся не использовать иначе.
Примечание: когда Вы отметите локально, git push не обновит теги на сервере. Используйте git push --tags для этого.
Необходимо заняться расследованиями git describe. Это дает уникальную строку, которая описывает текущее ответвление (или любой переданный идентификатор фиксации) с точки зрения последнего аннотируемого тега, количества фиксаций начиная с того тега и сокращенного идентификатора фиксации главы ответвления.
, По-видимому, у Вас есть единственное ответвление, что Вы выполняете управляемые выпуски сборки прочь. В этом случае я отметил бы раннюю фиксацию с известным форматом тега и затем использовал бы мерзавца, описывают с - опция соответствия описать текущую ГОЛОВУ относительно известный тег. Можно затем использовать результат мерзавца, описывают, как или если Вы действительно хотите просто единственное число, можно использовать regex для прерывания числа из тега.
Предположение, что Вы никогда не перематываете ответвление количество следующих фиксаций, будет всегда определять уникальную точку в истории ответвления.
, например, (использующий удар или подобный)
# make an annotated tag to an early build in the repository:
git tag -a build-origin "$some_old_commitid"
# describe the current HEAD against this tag and pull out a build number
expr "$(git describe --match build-origin)" : 'build-origin-\([0-9]*\)-g'
Как Вы, вероятно, знаете, мерзавец вычисляет хеш (число), который однозначно определяет узел истории. Используя их, хотя они строго не увеличиваются, кажется, что это было бы достаточно хорошо. (Еще лучше они всегда соответствуют источнику, поэтому если у Вас есть хеш, у Вас есть тот же код.) Они - большие числа, но главным образом можно обойтись приблизительно 6 из ведущих цифр.
, Например,
, Что ошибка была исправлена в 064f2ea...
Я использовал бы, "Маркирует" Create маркировкой каждый раз, когда у Вас есть успешное (или даже неудачный) сборка, и Вы сможете определить ту сборку навсегда. Это - не совсем то же, но это действительно обеспечивает те номера сборки, все еще предоставляя преимущества распределенной разработки.
В Mercurial вы можете использовать следующую команду:
# get the parents id, the local revision number and the tags
[yjost@myhost:~/my-repo]$ hg id -nibt
03b6399bc32b+ 23716+ default tip
См. hg identify