Not a kernel guy

Boost переехал в Subversion репозиторий….

Я как-то упустил из виду. Похоже, что Boost наконец-то переехал в Subversion реп…

Хорошая новость. Единственный минус — svn обрабатывает репозитарий слишком долго Да и пересобирать буст при малейшем изменении в сорце тоже накладно. Хотя, время покажет.

[...] Source control (revision control, source code management (SCM)) - по-русски это все обычно называют системами контроля версий. Контролировать ими можно много чего, но меня они, конечно, интересуют в плане работы с кодом. Сначала я кратко расскажу про системы контроля версий для тех, кто о них ничего не знает или знает мало, а потом пару слов скажу про выступление Линуса Торвальдса, в котором он рассказывает о Git’е. Зачем вообще нужен какой-то контроль за кодом? Затем, что без контроля получается бардак. На диске появляются бесконечные копии исходников с загадочными именами: MyProject1, MyProject.backup, MyProject.old, MyProject.oldest. Проку в них никакого нет, потому что все равно уже не вспомнить где какие изменения делались.Основная идея систем контроля версий - запоминать все внесенные изменения с комментариями. Понятно кто когда что менял, зачем. Главное - можно все эти изменения откатить. Ну а кроме этого систему контроля версий можно обвешать дополнительными фишками и рюшечками.Самые известные, которые чаще всего упоминаются - CVS, Subversion (SVN), Perforce. Все системы, что я перечислила, объединяет то, что это системы с одним, выделенным сервером, на котором и находится репозиторий с кодом. Скорее всего вы работали с какой-то из них. Если ни с какой не работали, то очень рекомендую поставить Subversion. Его легко и непринужденно можно погонять на одной локальной машине и получить полное представление о работе систем контроля версий. Небольшой словарик для понимания дальнейшего. Переводами народ себя обычно не утруждает :-).Транк (trunk) - основная ветка кодаБранч (branch) - ответвления (для экспериментов, например)Чекин (Check in (submit, commit)) - отправка кода в репозиторийЧекаут (Check out) - получение изменения из репозитория.Конфликты - возникают, когда несколько человек правят один и тот же код, конфликты можно разрешатьПатч - кусок с записанными изменениями, которые можно применить к репозиторию с кодом Традиционная схема работы с репозиторием в Open Source проектах такова. Есть некто Главный (пусть будет Ведущий программист, неважно). Программисты делают патчи, цепляют их к багам в багтракинговой системе. Главный просматривает их патчи, если все ОК - применяет к коду. В Second Life используется схема работы с патчами. В качестве багтракинговой системы там используется JIRA, в качестве системы контроля версий - SubVersion.В компаниях такая схема тоже иногда применяется, при работе со стажерами. Чтобы кто-то просматривал их код, прежде чем он попадет в репозиторий. Обычные же программисты, как правило, имеют право коммита.Вот выступление Линуса Торавальдса, в котором он рассказывает про им написанную систему контроля версий Git. Тон рассказа мне не очень понравился, Линус там периодически пытается несмешно шутить по поводу своей популярности. Кстати, по ходу доклада гугловцы упоминают, что у них используется Perforce.Линус не любит Perforce, не любит CVS, не любит SubVersion. Он ратует за распределенные системы контроля версий. Которые, мало того, что убирают точку отказа, но еще делают более простым процесс создания бранчей и позволяют смело экспериментировать с кодом, не вызывая комплексов “засабмитить не то”. Я думаю, Git получит рапространение хотя бы по тому, что его написал Линус. Еще пример использования распределенной системы контроля версий - Bazaar используется при работе над Ubuntu Linux. Большой список систем контроля версий можно посмотреть в Википедии.Ссылки по теме:Boost переехал в Subversion репозиторий [...]