История изменений

Но что делать, если нужно проставить версию компилируемого?

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

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

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

АбраКадабра какая-то вместо версий.

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

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

Но что делать, если нужно проставить версию компилируемого?

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

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

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

АбраКадабра какая-то вместо версий.

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

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

Но что делать, если нужно проставить версию компилируемого?

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

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

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

АбраКадабра какая-то вместо версий.

Жертвование инкрементальными номерами ревизий было ради распределенности систем контроля версий. Тут уж кому что важнее, ведь svn никто не запретил, можно использовать.

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

Но что делать, если нужно проставить версию компилируемого?

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

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

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

АбраКадабра какая-то вместо версий.

Жертвование инкрементальными номерами ревизий было ради распределенности систем контроля версий. Тут уж кому что важнее, ведь svn никто не запретил, можно использовать.

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