Comments 20
process.StartInfo.FileName = "\«c:\\Program Files (x86)\\Git\\cmd\\git.exe\»";Вы либо путь нормально определяйте, либо какой-нибудь NGit используйте. Лучше второе, ибо лучше переносимо.
Вместо «rev-list master --count» лучше получить время создания последней ревизии, перегнать его в timestamp, и уже его использовать. Иначе после git merge --squash может случиться уменьшение номера версии.
А ещё можно использовать билд-сервер типа TeamCity, который займётся этим за вас.
Ну и править лучше не регуляркой, а средствами Roslyn.
Так как не стал сильно заморачиваться, путь прописал прямо в код, а вид его такой потому, что обязытельно нужны кавычки, без них он не определяется как единое целое и пытается запустить программу «c:\Program» с параметром «Files»…
По поводу уменьшения версии при объединении читал. Я Вас правильно понял, что использовать именно timestamp в качестве инкрементного значения определения номера ревизии? Мне кажется, у Microsoft по такому принципу встроенный инкрементный модуль счета ревизии работает — при компиляции указывает количество секунд от начала текущих суток.
По поводу уменьшения версии при объединении читал. Я Вас правильно понял, что использовать именно timestamp в качестве инкрементного значения определения номера ревизии? Мне кажется, у Microsoft по такому принципу встроенный инкрементный модуль счета ревизии работает — при компиляции указывает количество секунд от начала текущих суток.
Так как не стал сильно заморачиваться, путь прописал прямо в код, а вид его такой потому, что обязытельно нужны кавычки, без них он не определяется как единое целое и пытается запустить программу «c:\Program» с параметром «Files»…
1) на билд-сервере запросто может быть 32-битная ОС
2) Git может быть установлен на диске D:
Мне кажется, у Microsoft по такому принципу встроенный инкрементный модуль счета ревизии работает — при компиляции указывает количество секунд от начала текущих суток.Ну вот надо от фиксированной даты секунды, а не от начала суток. Тогда будет постоянно возрастать.
По пунктам «1» и «2» я Вас понимаю, только и Вы меня поймите — у меня и дома, и на работе стоит 64 разрядная ось. Пользуюсь репозиторием единолично и, описанное в статье, решение позволяет реализовать инкременирование версий как раз для одного человека. Если же появится хотя бы еще один, то решение уже 100% даст сбой на первой же сборке после объединения веток.
По поводу места установки GIT — конечно, можно приложение научить считывать информацию из реестра о его местонахождении, или же вывести окно ручного ввода пути, или в файле вручную прописывать, но это будет актуально, опять же, при командной работе и в этом я полностью с Вами согласен.
По секундам мне не понравилось потому, что:
1. Компилирую проект. Получаю версию, скажем 1234.
2. Тут же делаю ребилд и получаю уже новую версию, например, 1345.
И на этом моменте возникает вопрос — сколько ревизий было между этими двумя сборками? 111? Нет. А сколько? А кто его знает?
Вот почему этот метод использовать не комильфо.
P.S.: с ревизиями заморочился потому, что мне интересно за сколько ревизий я достиг определенного результата.
По поводу места установки GIT — конечно, можно приложение научить считывать информацию из реестра о его местонахождении, или же вывести окно ручного ввода пути, или в файле вручную прописывать, но это будет актуально, опять же, при командной работе и в этом я полностью с Вами согласен.
По секундам мне не понравилось потому, что:
1. Компилирую проект. Получаю версию, скажем 1234.
2. Тут же делаю ребилд и получаю уже новую версию, например, 1345.
И на этом моменте возникает вопрос — сколько ревизий было между этими двумя сборками? 111? Нет. А сколько? А кто его знает?
Вот почему этот метод использовать не комильфо.
P.S.: с ревизиями заморочился потому, что мне интересно за сколько ревизий я достиг определенного результата.
Вы определитесь, вы либо «сами дома лично пользуетесь», либо выкладываете в общественное обозрение и пользование. Подход к переносимости и универсальности решения в зависимости от этого принципиально разный.
Согласен с Вами, как и с тем, что не мало людей пользуются такой же схемой, как у меня и, думаю, им также будет интересен довольно легкий метод, описанный здесь.
И да, кто-то смотрит на статью как на решение для себя, а кто-то как на общепрограмистское решение вопроса.
Разница в том, что для большинства проектов в команде, как и требований самих программистов, в Интернетах не мало решений имеются, которые я и сам видел и, все же, решил написать данную статью, так как именно этого варианта оглашено не было)
И да, кто-то смотрит на статью как на решение для себя, а кто-то как на общепрограмистское решение вопроса.
Разница в том, что для большинства проектов в команде, как и требований самих программистов, в Интернетах не мало решений имеются, которые я и сам видел и, все же, решил написать данную статью, так как именно этого варианта оглашено не было)
Не совсем в тему, но кто знает, как это же автоматизировать в Android+Gradle+Idea 14?
Есть отличный плагин под названием BuildVersionIncrement. Зачем изобретать велосипед?
Сайт проекта
Версия под 2012/2013
Сайт проекта
Версия под 2012/2013
Глянул я эту программку и, мягко говоря, не впечатлила она меня.
Не впечатлила потому, что при любом билде, будь то дебаг и/или релиз, устанавливать определенные значения, а именно те, которые на скрине видны. Надеюсь для других перевод не нужен.
Описанный же проект в статье позволяет инкреминировать номер билда только при компиляции релиза, а номер ревизии всегда.
Также я согласен, что в Инете полно рабочих примеров по данному вопросу, вот только меня они не устраивают, вследствие чего и было принято решение о написании своей функции.
Не впечатлила потому, что при любом билде, будь то дебаг и/или релиз, устанавливать определенные значения, а именно те, которые на скрине видны. Надеюсь для других перевод не нужен.
Описанный же проект в статье позволяет инкреминировать номер билда только при компиляции релиза, а номер ревизии всегда.
Также я согласен, что в Инете полно рабочих примеров по данному вопросу, вот только меня они не устраивают, вследствие чего и было принято решение о написании своей функции.
Не претендую на 100% полноту, но мы обновляем версию только на билд сервере, никаких Pre-Build Event, поскольку реально обновленный номер версии нужен только на рабочих инстансах (ИМХО. опять же).
Для обновления версии используется AssemblyInfo из MSBuild.ExtensionPack, что несколько надежнее регулярных выражений.
А в качестве номера ревизии используется номер сборки, т.к. как уже упомянуто выше, ваш способ генерации не совсем корректен.
Для обновления версии используется AssemblyInfo из MSBuild.ExtensionPack, что несколько надежнее регулярных выражений.
А в качестве номера ревизии используется номер сборки, т.к. как уже упомянуто выше, ваш способ генерации не совсем корректен.
Это да, он ненадежен при работе с ветками. Вернее сказать, он вообще не подходит.
Я же работаю один и использую GIT для работы как дома, так и в офисе, что упрощает мне задачу, исключая перенос кода на флешке, которую как минимум могу где-нибудь забыть. Так что конкретно для моих целей описанный вариант более чем достаточен :)
Я же работаю один и использую GIT для работы как дома, так и в офисе, что упрощает мне задачу, исключая перенос кода на флешке, которую как минимум могу где-нибудь забыть. Так что конкретно для моих целей описанный вариант более чем достаточен :)
Можно пойти и сложным путем запоминания в какой-нибудь файл timestamp факта проверки версий, а при следующих проверках выводить количество коммитов после указанной даты.
Таким образом, получим, что ВЧЕРА люди отправляли коммиты, объединяли, отменяли, да и выполняли прочие прелести работы, а СЕГОДНЯ при проверке считываю из гита количество коммитов в период со ВЧЕРА до СЕГОДНЯ.
Далее, легким математическим путем, например, ко вчерашним 27 коммитам плюсуем дельту между СЕГОДНЯ и ВЧЕРА, и, условно, она будет равняться 15. Таким образом, получим ревизию № 42 и вновь запомним дату проверки состояния на СЕГОДНЯ, чтобы вновь определить новую версию на ЗАВТРА.
Хотя… Что-то я вообще поизвращался с вариантом))) Конечно, опять же будет работать, если человек, отвечающий за обновление версии, будет один, то бишь, он сам раз в сутки запускает скрипт… Ужас… Не годится этот метод… Извращение полнейшее… :-)
Таким образом, получим, что ВЧЕРА люди отправляли коммиты, объединяли, отменяли, да и выполняли прочие прелести работы, а СЕГОДНЯ при проверке считываю из гита количество коммитов в период со ВЧЕРА до СЕГОДНЯ.
Далее, легким математическим путем, например, ко вчерашним 27 коммитам плюсуем дельту между СЕГОДНЯ и ВЧЕРА, и, условно, она будет равняться 15. Таким образом, получим ревизию № 42 и вновь запомним дату проверки состояния на СЕГОДНЯ, чтобы вновь определить новую версию на ЗАВТРА.
Хотя… Что-то я вообще поизвращался с вариантом))) Конечно, опять же будет работать, если человек, отвечающий за обновление версии, будет один, то бишь, он сам раз в сутки запускает скрипт… Ужас… Не годится этот метод… Извращение полнейшее… :-)
Инкриминирование — (от лат. in «в» и crimen «вина» преступление), предъявление конкретному лицу обвинения в совершении преступления.
Инкремент, инкрементирование (от англ. increment «увеличение») — операция в языках программирования, увеличивающая переменную.
Пожалуй, можно внести правки в заголовок и в текст статьи?
Инкремент, инкрементирование (от англ. increment «увеличение») — операция в языках программирования, увеличивающая переменную.
Пожалуй, можно внести правки в заголовок и в текст статьи?
Использовать
Сами применяем такой костыль (гитовский хук), который поднимает номер ревизии при мердже в мастер.
Минусы:
— не работает при мердже с конфликтом
— не работает если мерджить из других веток
— поднимает только номер ревизии
— не ставит тэг с версией автоматически
git rev-list master --count — это мысль.Сами применяем такой костыль (гитовский хук), который поднимает номер ревизии при мердже в мастер.
Минусы:
— не работает при мердже с конфликтом
— не работает если мерджить из других веток
— поднимает только номер ревизии
— не ставит тэг с версией автоматически
Sign up to leave a comment.
Полуавтоматическое инкрементирование версии проекта при работе с GIT в Visual Studio