Мы в своей работе используем не голый VCS, а с web-оболочкой. В нашем случае, это GitLab.
У него достаточно приятный интерфейс, довольно удобная система обработки merge request, CI. Встроенным трекером не пользуемся, так как есть Jira.
VCS — это лишь базовый функционал, а для удобства команды требуются более высокоуровневые вещи.
Понятие «лучшее» очень сильно субъективировано и зависит от конкретного варианта использования. Без сомнения у Mercurial гораздо более низкий порог старта и для маленькой команды он проще. Но в большой команде, где активно используются временные ветки и управление правами на основе шаблонов имен веток, Git даёт преимущества.
Добрый день.
Нет, запроса в проект я не делал и в имеющемся виде не считаю это нужным. Есть несколько аспектов.
Нелинейные функции по своей природе очень отличаются между собой и для качественной подгонки нужно иметь в виду специфические условия и области сходимости.
В отличие от линейной регрессии сложно описать универсальный механизм обработки.
Например, для большинства нелинейных функций нельзя выполнить «обезразмеривание», что, в свою очередь, для линейной регрессии даёт существенное улучшение сходимости и устойчивости решения.
Я считаю переход к нелинейным моделям мерой вынужденной и надо понимать их негативные стороны. Моя работа показывает качественную возможность решения таких задач, а уже меры предосторожности — дело разработчиков.
В TFS такие свойства, как выходной каталог, прекрасно наследуются вдоль всей цепочки. Я уже забыл, как это было сделано, но такая возможность в msbuild точно есть.
Давайте не мешать французское с нижегородским. TFS и MSBuild вещи немного разные. У нас в команде не получилось нормально передавать кастомные свойства (версии 3.5 и 4.0), например, полностью квалифицированный номер сборки, кроме как прямой передачей при вызове файла targets. Во-вторых, места агрегации dll, msi и отчетов по тестам разные. Как это нормально оформить в MSBuild?
Ещё один интересный аспект — это работа версии MSBuild x64. Непонятно каким образом, но многие дополнительные task'и не работают в этой версии. Ярким примером можно привести Wix.
Но главный недостаток для меня лично — это невозможность в одном скрипте и загружать, и использовать task'и.
Я не хочу навязывать один инструмент. Мне интересен опыт сообщества по допиливанию функционала «из коробки» под собственные весьма специфичные условия.
Насчет необходимости изучения PowerShell исключительно для сборки проектов меня терзают смутные сомнения. Ну, а весёлые пародии из PS на утилиты Unix полностью отбивают желание его изучать.
Имена веток публикуются среди всех участников, поэтому в качестве имен обычно используют устойчивые во времени номера версий.
Если в проекте одновременно поддерживается столько версий, то мне искренне жаль его менеджера.
Если хочется порядка в «большом» хранилище, то локальную историю можно сжимать, прежде чем пересылать на сборку. Но если вы перешлете на сборку гига-патч, то в результате бисекции вы получите «ищите иголку где-то в этом стоге».
У него достаточно приятный интерфейс, довольно удобная система обработки merge request, CI. Встроенным трекером не пользуемся, так как есть Jira.
VCS — это лишь базовый функционал, а для удобства команды требуются более высокоуровневые вещи.
Как говорил Фредерик Брукс в своей бессмертной книге: «No silver bullet ©»
Нет, запроса в проект я не делал и в имеющемся виде не считаю это нужным. Есть несколько аспектов.
Нелинейные функции по своей природе очень отличаются между собой и для качественной подгонки нужно иметь в виду специфические условия и области сходимости.
В отличие от линейной регрессии сложно описать универсальный механизм обработки.
Например, для большинства нелинейных функций нельзя выполнить «обезразмеривание», что, в свою очередь, для линейной регрессии даёт существенное улучшение сходимости и устойчивости решения.
Я считаю переход к нелинейным моделям мерой вынужденной и надо понимать их негативные стороны. Моя работа показывает качественную возможность решения таких задач, а уже меры предосторожности — дело разработчиков.
Надеюсь, на Ваш вопрос я ответил.
Давайте не мешать французское с нижегородским. TFS и MSBuild вещи немного разные. У нас в команде не получилось нормально передавать кастомные свойства (версии 3.5 и 4.0), например, полностью квалифицированный номер сборки, кроме как прямой передачей при вызове файла targets. Во-вторых, места агрегации dll, msi и отчетов по тестам разные. Как это нормально оформить в MSBuild?
Ещё один интересный аспект — это работа версии MSBuild x64. Непонятно каким образом, но многие дополнительные task'и не работают в этой версии. Ярким примером можно привести Wix.
Но главный недостаток для меня лично — это невозможность в одном скрипте и загружать, и использовать task'и.
Я не хочу навязывать один инструмент. Мне интересен опыт сообщества по допиливанию функционала «из коробки» под собственные весьма специфичные условия.
NAnt под Mono уже уже работает.
Инструкции по отделению тестового движка от VS есть тут.
Мы запускали MSTest так:
Того же эффекта можно достичь, используя MSBuild Extension Pack.
Если в проекте одновременно поддерживается столько версий, то мне искренне жаль его менеджера.
Если хочется порядка в «большом» хранилище, то локальную историю можно сжимать, прежде чем пересылать на сборку. Но если вы перешлете на сборку гига-патч, то в результате бисекции вы получите «ищите иголку где-то в этом стоге».