«Доказано», «большинство» — это всё слишком громкие слова. Тут дело в другом — интерфейс, рассчитанный только на чайников использовать профессионально очень тяжело. А профессиональный интерфейс требует времени на освоение, зато позволяет эффективно выполнять задачи.
Хорошая консоль действительно удобнее для профессионала, чем плохой гуй. Главная же проблема в том, что производители гуёв начисто игнорируют наличие профессионалов, оперируют при этом какими-то загадочным словами типа «интуитивно понятный», «простой в освоении» и так далее.
Перед некоторыми ЖД-переездами таки ставят, только наоборот. Они поднимаются, когда едет поезд, так что их переехать нельзя, если двигаться вперёд, но назад — можно.
Не люблю аналогии, но тут прямо-таки не обойтись без них.
Рабочий инструмент нужно содержать в порядке. Иначе он ржавеет и начинает плохо выполнять свои прямые обязанности. Так и репозиторий очень легко загадить, причём загадить так, что проблема всплывёт лишь через полгода, например.
Использование соответствующих инструментов рецензировани кода очень помогает в жизни, это я говорю как обычный девелопер, напрямую работавший с такой системой. Это достаточно просто, надёжно, быстро и полезно.
Я не говорил такого. Я лишь говорил, что в репозитории может быть что угодно, но вне основных веток. Каждый девелопер может себе сколько угодно веток насоздавать, но они служат лишь одной цели — чтобы код не потерялся.
Ничего хорошего из этой идеи не выйдет. Люди из QA думают совершенно по-другому, не как девелоперы. Да и чисто психологически не очень комфортно искать потенциальные косяки в собственнописанном продукте.
> Касаемо правила «код может попасть в репозиторий только после того...» — такое может породить только больная голова. Мотивация такого решения от меня ускользает.
Мотивация очень простая. Контроль за качеством кода, соблюдением принятого подхода и так далее. Штука необычайно полезная, хотя и отнимает какое-то время, но зато позволяет оценивать чужой код и писать более стройный и согласованный код.
> Репозиторий системы контроля версий — это не «дом высокой культуры быта» и не образцово-показательное хранилище исходников. Это, прежде всего, рабочий инструмент, так что и отношение к нему должно быть соответствующее.
Такой подход работает только для идеальных сферических программистов в вакууме. Реальность прозаичнее и грубее. Естественно, не весь код проходит через ревью. У каждого девелопера есть своя ветка и так далее. Но весь код в главные ветки обязан быть проревьюенным.
Ревью делается через Code Collaborator. Процесс оптмимизирован и много времени не отнимает. Естественно, что SVN, CC, bugzilla интегрироанны между собой.
Про структуру репозитория особо распространяться не буду, скажу лишь, что она самая обычная, примерно как в KDE4.
Хорошая консоль действительно удобнее для профессионала, чем плохой гуй. Главная же проблема в том, что производители гуёв начисто игнорируют наличие профессионалов, оперируют при этом какими-то загадочным словами типа «интуитивно понятный», «простой в освоении» и так далее.
bugs.php.net/bug.php?id=41373
bugs.php.net/bug.php?id=41364
Рабочий инструмент нужно содержать в порядке. Иначе он ржавеет и начинает плохо выполнять свои прямые обязанности. Так и репозиторий очень легко загадить, причём загадить так, что проблема всплывёт лишь через полгода, например.
Использование соответствующих инструментов рецензировани кода очень помогает в жизни, это я говорю как обычный девелопер, напрямую работавший с такой системой. Это достаточно просто, надёжно, быстро и полезно.
Мотивация очень простая. Контроль за качеством кода, соблюдением принятого подхода и так далее. Штука необычайно полезная, хотя и отнимает какое-то время, но зато позволяет оценивать чужой код и писать более стройный и согласованный код.
> Репозиторий системы контроля версий — это не «дом высокой культуры быта» и не образцово-показательное хранилище исходников. Это, прежде всего, рабочий инструмент, так что и отношение к нему должно быть соответствующее.
Такой подход работает только для идеальных сферических программистов в вакууме. Реальность прозаичнее и грубее. Естественно, не весь код проходит через ревью. У каждого девелопера есть своя ветка и так далее. Но весь код в главные ветки обязан быть проревьюенным.
Про структуру репозитория особо распространяться не буду, скажу лишь, что она самая обычная, примерно как в KDE4.