Также очень рекомендую Practical Perforce (книга, платная, но... можно найти).
Мы работаем с Perforce, поэтому все ответы могут быть специфичны для этой SCM, или только для SCM с централизованным репозиторием.
Видимая мне часть репозитория ~60000 файлов; так или иначе работаем с подмножеством ~1000-2500 файлов (посчитать сложно )
Q>А вы для каких случаев создаёте отдельные ветви?
Для работы над экспериментальными фичами; длительными рефакторингами; просто над крупными кусками функциональности, при работе над которыми удобно часто коммитить в разрез с policy родительской ветки.
Q>Какой длины?
Не понял.
Q>Как часто синхронизируетесь с транком?
Trunk -> Branch — как можно чаще
Trunk <- Branch — в точках стабильности Branch (т.е. в таких, где код в Branch удовлетворяет policy Trunk; всё как в учебнике)
Q>Создаёте ли отдельный репозиторий (в случае DVCS)?
(Неприменимо)
Q>Удаляете ли ветви после вливания в транк?
Обычно нет.
Q>Возникают ли проблемы независимой поддержки параллельных ветвей?
Редко.
Q>Используете ли плагины и расширения системы контроля версий для наглядной визуализации топологии ветвления?
На главной ветке никакой разработки нету.
Там только стабильные, оттестированные версии.
Как только начинается проект, делаем отдельную ветку на проект.
Далее смотрим какие фичи планируется реализовать.
Фичи группируем так, чтобы их можно было реализовывать относительно параллельно и независимо.
Для каждой такой группы фич создается ветка.
Каждый девелопер, работающий над группой фич, создает свою ветку и работает только в ней.
Т.е. в итоге получается иерархия из 4-х веток:
* главная ветка
** ветка проекта
*** ветка группы фич (по одной ветке на группы)
**** личная ветка разработчика
Синхронизация с родительских веток в дочерние происходит как можно чаще.
Из дочерних в родительские — как только достигается стабильность в дочерней ветке.
Т.е. если девелопер видит, что у него все стабильно,
то он может смерджить свою часть в родительскую ветку группы фич.
Если группа фич достигла стабильности, то ее можно смерджить в ветку проекта.
Прежде чем мерджить что-то с дочерних веток в родительские обязательно нужно
все смерджить все с родительской ветки в дочернюю.
На всех ветках для группы фич настроен "ночной билд" с запуском всех тестов.
Несмотря на кажущееся обилие мерджей, оверхед минимальный.
Работает это все дело только потому что заранее планируются версии продукта и
фичи, которые планируются реализовать.
Здравствуйте, Qbit86, Вы писали:
Q>Добрый вечер, уважаемые коллеги!
Q>А вы для каких случаев создаёте отдельные ветви? Какой длины? Как часто синхронизируетесь с транком? Создаёте ли отдельный репозиторий (в случае DVCS)? Удаляете ли ветви после вливания в транк? Возникают ли проблемы независимой поддержки параллельных ветвей? Используете ли плагины и расширения системы контроля версий для наглядной визуализации топологии ветвления?
Q>И вопрос, ради которого затевался топик: какие соглашения об именовании ветвей используете? Включаете ли версию, дату, имя разработчика, название фичи? Пробелы, точки, дефисы, CamelCasing? Какие есть naming best bractises?
Здравствуйте, Qbit86, Вы писали:
Q>Это не управляемость. Это лишние, внешние, искусственные ограничения — учитывать ещё и гранулярность коммитов.
Это именно управляемость. Чем меньше задача, там легче ее оценить, запланировать, сделать и протестировать. В случае достаточно мелкой гранулярности (<8 часов на задачу) конфликтов при коммите вообще не возникает. Если же задача занимает неделю, то ее трудно точно оценить, трудно синхронизировать с другими изменениями и уж почти наверняка при коммите по этой задаче возникнут конфликты. А спрогнозировать возникновение конфликтов и затраты на их разрешение практически нереально.
Q>Да, если не сложно. Это, наверное, ортогонально топику, но тем не менее.
Здравствуйте, frogkiller, Вы писали:
F>ЗЫ. В случае разработки в транке такая ситуация разруливается автоматически — кто первый закоммитил — того и тапки. F>Причём в 99% случаев такой конфликт обнаружится на раннем этапе — при первой же попытке коммита второго изменения.
Ну и чем, в указанном тобой смысле, отличается «апдейт/коммит» от «синхронизация бранча с транком/синхронизация транка с бранчем»?
F>А расскажи тогда, как при такой концепции разруливается ситуация исключающих друг друга изменений одних интерфейсов в двух бранчах?
Во-первых, изменения интерфейсов (как наиболее уязвимых частей библиотеки, см. пункт Abstractions) всегда должны продумываться и согласовываться до внесения ломающих изменений.
Во-вторых, разруливаются примерно так же, как и при наличии исключающих друг друга изменений в разных рабочих копиях разных разработчиков при работе с единственным транком. В литературе по VCS такая штатная ситуация называется «Конфликт». Странно, что ты не слышал.
F>И там и там в итоге имеется нехилый профит в функциональности — все довольны... до момента, когда это всё надо слить в trunk.
Нет. Проблемы всплывут не во время вливания brahch→trunk, а во время синхронизации trunk→brahch. Последнее рекомендуется делать как можно чаще.
Здравствуйте, Qbit86, Вы писали: Q>Добрый вечер, уважаемые коллеги! Q>А вы для каких случаев создаёте отдельные ветви?
Если фича: долгая/ломающая/ее делают несколько человек/нужно иметь возможность собрать проект без нее — то ветка. Ну по сути — что-то вроде первой пары правил.
Q>Какой длины?
В каких единицах?
Q>Как часто синхронизируетесь с транком?
Из транка в ветку почаще, из ветки в транк — когда фича более-менее готова. Далее фича докручивается уже в транке.
Q>Удаляете ли ветви после вливания в транк?
Да, svn же.
Q>Возникают ли проблемы независимой поддержки параллельных ветвей?
Да, бывало. На мой взгляд, типичные источники проблем:
— В бранче было сделано нечто, не относящееся непосредственно к реализуемой в нем фиче.
— Фичи, вынесенные в разные бранчи, оказались связаны между собой.
Q>Используете ли плагины и расширения системы контроля версий для наглядной визуализации топологии ветвления?
Пока не было необходимости.
Q>И вопрос, ради которого затевался топик: какие соглашения об именовании ветвей используете?
Обычно пара слов, кратко обозначающая назначение.
по непрерывной интеграции. Транк в любой момент времени должен проходить перечисленные там проверки, это его инвариант.
Мы как-то пытались разрабатывать подобным образом — чтобы каждая ревизия в транке была идеальна чуть менее, чем полностью. В итоге отказались, т.к. в итоге разработка уехала в отдельные ветки, и легче оказалось поддерживать неидельный транк, решая проблемы по мере их возникновения (и возможности).
Здравствуйте, Qbit86, Вы писали: Q>Под частой синхронизацией подразумевается частое чтение из транка, а не частое его изменение.
Вполне очевидно, что читать транк чаще, чем он меняется, невозможно. Поэтому высокая частота вливания из транка в бранчи подразумевает высокую частоту обратного процесса. В итоге, на мой взгляд, суперстабильный транк подходит для обмена изменениями только между супернезависимыми командами разработчиков.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну все-таки не совсем. Коммит должен вносить осмысленные изменения в код. Не "доработал до вечера и пошел спать", а "сделал фичу XXX" или "починил багу YYY". Иначе вы используете систему контроля версий просто в качестве бакапа, и не имеете осмысленной истории изменений.
«Сделанная фича» может быть на разных уровнях готовности. Между «собирается и вроде как работает» и «вычищена так, что FxCop носа не подточит» может пролегать много времени. Запрет не коммит до выполнение этих задач — это как запрет автору статьи нажимать Save в Word'е, пока текст не прочитает корректор. Вы предлагаете, перед уходом работы не сохранять рабочую копию? Я не хочу так рисковать дневными наработками.
Q>>Но в случае работы в транке, «Коммит» оказывается перегруженным, он выполняет ещё и функцию publishing'а кода. Со всеми вытекающими. Даже в случаях «мелких фич» быстрый комит уже сделать нельзя. Приходится делать апдейт, мерджить, разруливать конфликты — высокий риск потери незакоммиченных («несохранённых») данных. Если коммит прошёл гладко, то всё равно надо дожидаться отклика CI-сервера, прогона тестов, инспекции кода.
Pzz>Это значит, что у вас слишком много бюрократии в текущей ветке. Разработчики должны свободно коммитить в текущую ветку при условии, что они предпринимают разумное количество усилий не сломать программу. Т.е., как минимум, перед коммитом надо убедиться в том, что программа собирается, и если изменения затрагивают уже работающий код, хоть слегка его оттестировать.
В изолированной ветке разработчика бюрократии нет, она прикручена только к транку. Но при желании допустимо прикрутить бюрократию к какой-нибудь feature branch. И это называется не бюрократия, а планка качества.
Pzz>...при условии, что они предпринимают разумное количество усилий не сломать программу. Т.е., как минимум, перед коммитом надо убедиться в том, что программа собирается, и если изменения затрагивают уже работающий код, хоть слегка его оттестировать.
«Убеждаться» должна машина. Проверка условий должна выполняться автоматически. Как я могу доверить коллегам не забывать следить за качеством их кода, если я не доверяю даже себе?
Здравствуйте, frogkiller, Вы писали:
F>>>Только почему нельзя закоммитить рабочую копию? Q>>Потому что SVN-сервер не пропустит! Он потребует сделать предварительный апдейт. И при этом придётся сделать merge и resolve conflicts. И всё это — «наживую», в «красной» рабочей папке, малейшая ошибка чревата безвозвратной потерей локальных изменений. F>И?
Не буду в шестой раз повторять, почему манипуляции с сохранёнными данными (в нашем случае, с сохранённой историей ревизий) лучше, чем с несохранёнными.
F>Закоммитить не проблема
Закоммитить не проблема, предварительно проапдейтить проблема.
F>возможной проблемой (для твоего подхода) будет то, что закоммиченное может даже и не собираться, не говоря уже о тестах.
Для твоего подхода. Это ведь ты предлагаешь «раннее использование» недоделанного кода?
F>Это зависит от дисциплины и от разных вспомогательных средств.
Называется это вспомогательно средство «сервер непрерывной интеграции», он и проверяет транк на поломанность. Только использовать его предполагается в режиме «поломал — починил», а не «не доделал — не доделал — почти доделал — допилил». В некоторых CI-серверах есть такой счётчик пользователя как карма. Не проверил билд перед коммитом, сломал транк — получи минус в карму :)
F>Например, можно слать письма-напоминалки сломавшему сборку/тест.
Да хоть твиттер-сообщения.
F>Да, транк становится нестабильным — ну и что с того. Заказчику и тестерам можно показывать специальные стабильные бранчи, которые потом и релизить.
Где ж их взять-то, стабильные бранчи? Как поймать момент стабильности транка, чтоб ответвить от него стабильный бранч?
Я так понимаю, ты шаг за шагом всё таки склоняешься к необходимости бранчевания.
F>А теперь представь, что это не два разработчика, а две команды, человек по 30 в каждой, они делают по сотне коммитов в день, а кроме них есть ещё несколько команд, которые тоже не сидят сложа руки. Тут будет сразу несколько таких обменных бранчей, и они разъедутся очень-очень быстро.
А теперь представь, что они одновременно коммитят неконсистентные, промежуточные шаги в транк.
Бранчевание, поддержка непротиворечивости и чистоты стабильных веток — это общепринятая практика. Никто так просто не позволит коммитить в стабильные ветки ядра Линукса. Но это не повод не коммитить вообще.
F>Вывод — при разработке в транке не надо часто синхронизировать с ним бранчи.
Нужно всё как можно чаще (коль скоро это не нарушает других ограничений) синхронизировать. Merge early, merge often.
F>Проще отвести новый бранч и немного допилить до стабильного состояния ;)
. Отдельные ветки для фич когда-то использовались, но потом от них за бесполезностью отказались — стали просто использовать две видимые извне ветки, коммитить изменения в рабочую и регулярно обновлять из нее публичную.
И напоследок о тех, кто не использует РСКВ:
In Windows... there are far too many developers to access one central repository. So Windows has a tree of repositories: developers check in to the nodes, and periodically the changes in the nodes are integrated up one level in the hierarchy. At a different periodicity, changes are integrated down the tree from the root to the nodes. In Windows, the node I was working on was 4 levels removed from the root. The periodicity of integration decayed exponentially and unpredictably as you approached the root so it ended up that it took between 1 and 3 months for my code to get to the root node, and some multiple of that for it to reach the other nodes. It should be noted too that the only common ancestor that my team, the shell team, and the kernel team shared was the root.
Здравствуйте, gandjustas, Вы писали:
G>>>Если нужен Save без publish, то вполне можно использовать такую фичу. В TFS она называется shelve, в SVN подобной нету, про другие СКВ не знаю. MC>>В svn можно создать ветку и текущие изменения закоммитить туда. G>Только появляется геморрой со свитчем веток, их именованием и тому подобным. Это уже не работает как кнопка Save.
git stash
Здравствуйте, Qbit86, Вы писали:
Q>А вы для каких случаев создаёте отдельные ветви? Какой длины? Как часто синхронизируетесь с транком? Создаёте ли отдельный репозиторий (в случае DVCS)? Удаляете ли ветви после вливания в транк? Возникают ли проблемы независимой поддержки параллельных ветвей? Используете ли плагины и расширения системы контроля версий для наглядной визуализации топологии ветвления?
Могу рассказать как это организованно у нас. Все разработка ведется в транке. Что, кстати, совершенно не отменяет того факта что код в транке большую часть времени компилируется и проходит тесты. После каждого отгруженного релиза создается ветвь со стандартным именем вида release_19.260.17.18327. Если требуется поддержка именно этой версии в эту ветвь вносятся изменения. И сразу же эта ветвь мержится с транком. Ни в каких других случаях ветви не создаются. ИМХО, оверхед на мердж ветвей превышает все преимущества от из использования. В будущем планируем переходить на DVCS. Скорее всего это приведет к тому, что на новые фичи разработчики будут создавать локальные ветки, которые будут мерджится в транк по завершении работ. Теоретически это уменьшит количество мерждей и улучшит качество кода в транке.
Я встречал попытки более широко использовать бранчи, но они всегда приводили к одному из двух результатов: либо к большому оверхеду на войну с VCS либо к бардаку. В клинических случаях приходилось даже держать целую интеграционную команду, которая только и занималась тем что мерджила сотни веток в один продукт.
Здравствуйте, gandjustas, Вы писали:
G>В других системах есть другие возвожности сохраненения изменений, кроме веток, рассчитанные на определенные сценарии работы. Они определенно удобнее веток будут для этих сценариев.
Например? Shelves? Они не для коллаборации (АКА взаимодействия). Они для временного сохранения изменений без образования бранча, для демонстрации своих результатов без образования бранча. По сути это — кастрированный бранч.
Какие ещё способы взаимодействия через VCS, но без бранчей ты знаешь?
A>>Вводная информация: проект с 30-40 разработчиками в одной команде (одна компания) и с сотней разработчиков в общей команде, разбросанной по всему миру (большая корпорация с несколькими контракторами). G>Смотря какая СКВ и какой проект.
Приведи свой пример — ты сказал, что есть способы безболезненного взаимодействия через VCS, но без бранчей. Назови свой пример подобного взаимодействия с указанными условиями.
G>Существует несколько branching strategies, которые фактически отличаются тем насколько часто надо создавать ветки.
Ты сказал branching strategies. Т.е. ветвление таки должно быть?
G>Большое количество веток ведет к оверхеду по слиянию веток, но делает разработку фич отдельными командами или людьми более независимой.
В чем заключается оверхед? В том, что надо мержить с веток на главную линейку? Ты хоть какие shelves используй — без слияния девелоперских изменений не обойдешься.
G>Общая формула — частота создания веток обратно пропорциональна уровню централизованности разарботки.
Неверно. Чем больше централизована разработка, тем больше необходимость ветвления для отдельного разработчика. Представь единый центральный trunk (ситуация центральнее некуда), десяток разработчиков. Ты им предлагаешь жить без веток? Допустим. Типа договариваются между собой насчет регулярных мержей и т.п. (глюк, но допустим.) Появляется ещё десяток разработчиков ... Твои действия? Разумеется, ты их всех хором отправляешь на отдельные ветки или shelve'ы (смотря что больше принято в твоей VCS). Получатся — централизованная разработка — много веток.
Повторю — кажущийся оверхед по мержам — ничто по сравнению с бардаком, который получаешь при отсутствии веток.
Здравствуйте, Miroff, Вы писали:
M>Могу рассказать как это организованно у нас. Все разработка ведется в транке. Что, кстати, совершенно не отменяет того факта что код в транке большую часть времени компилируется и проходит тесты.
Но ставит крест на стратегии «commit often». Ходишь, как по минному полю; шаг влево, шаг вправо — и локальные изменения утеряны. Например, при апдейте, мерджевании и ошибке в разруливании конфликтов.
M>После каждого отгруженного релиза создается ветвь со стандартным именем вида release_19.260.17.18327. Если требуется поддержка именно этой версии в эту ветвь вносятся изменения. И сразу же эта ветвь мержится с транком.
При этом же приходится пересоздавать ветвь? В том смысле, что при «reintegrate branch into trunk» ветку надо закрывать, согласно рекомендациям svn-book'а. Если её продолжать, то могут быть проблемы с синхронизацией с транком.
Кстати, а почему для этих целей создаётся ветвь, а не тэг? (Впрочем, в Subversion это одно и то же.)
По какому принципу строится номер 19.260.17.18327? Он генерируется автоматически или прописывается руками согласно какому-то соглашению?
Здравствуйте, Qbit86, Вы писали:
Q>«Сделанная фича» может быть на разных уровнях готовности. Между «собирается и вроде как работает» и «вычищена так, что FxCop носа не подточит» может пролегать много времени. Запрет не коммит до выполнение этих задач — это как запрет автору статьи нажимать Save в Word'е, пока текст не прочитает корректор. Вы предлагаете, перед уходом работы не сохранять рабочую копию? Я не хочу так рисковать дневными наработками.
Я предлагаю писать в сорс контрол тогда и только тогда, когда вы можете выразить суть изменения осмысленной записью в логе. Запись "рабочий день кончился" не является осмысленной, как и отсутствие какой-либо записи.
Если программисты не могут выразить суть своей деятельности записями в логе, значит у вас что-то не так, либо у них в голове, либо в вашей организации.
А если вы боитесь потерять файлы, вам нужна система бакапов, а не сорс контрол.
Pzz>>Это значит, что у вас слишком много бюрократии в текущей ветке. Разработчики должны свободно коммитить в текущую ветку при условии, что они предпринимают разумное количество усилий не сломать программу. Т.е., как минимум, перед коммитом надо убедиться в том, что программа собирается, и если изменения затрагивают уже работающий код, хоть слегка его оттестировать.
Q>В изолированной ветке разработчика бюрократии нет, она прикручена только к транку. Но при желании допустимо прикрутить бюрократию к какой-нибудь feature branch. И это называется не бюрократия, а планка качества.
Если у вас планка качества поднята столь высоко, что постоянно мешает работать, это не планка качества, а бюрократия.
Я очень рекомендую доверять разрабочикам коммитить в общий сорс контрол, а всякие там code review делать в режиме постмодерирования. Осознание того факта, что ошибка разработчика станет проблемой для многих людей, очень повышает уровень ответственности в коллективе и способствует профессиональному росту ваших людей (кроме очень редких исключений, но от тех, кто не хочеть взрослеть, надо постепенно избавляться).
Pzz>>...при условии, что они предпринимают разумное количество усилий не сломать программу. Т.е., как минимум, перед коммитом надо убедиться в том, что программа собирается, и если изменения затрагивают уже работающий код, хоть слегка его оттестировать.
Q>«Убеждаться» должна машина. Проверка условий должна выполняться автоматически. Как я могу доверить коллегам не забывать следить за качеством их кода, если я не доверяю даже себе?
В этом заключается ваша огромная проблема. Если вы поручаете что-то людям, вы должны им доверять. Несмотря на тот факт, что они 1) ошибаются 2) делают все не так, как сделали бы вы 3) не понимают, что идеальная модель жизни, существующая в вашей голове, воистинну идеальна
Важно добиваться не того, чтобы не было ошибок (так не бывает). Важно добиваться того, чтобы последствия ошибок быстро исправлялись
Здравствуйте, Pzz, Вы писали:
Pzz>Я бы провел A1, A2 и А3 отдельными коммитами. Это почти всегда возможно.
Наоборот. Это почти всегда нарушает инварианты транка.
Q>>Я боюсь потерять не только файлы, но и историю их изменений.
Pzz>Ну, если пункты в вашей истории проставлены так же случайно, как люди нажимают кнопку Save, то что в ней ценного?
Во-первых, не так же случайно (к слову про осмысленный лог). Во-вторых, не хочется терять возможность откатиться назад, причём гранулярность шага не должна быть большой. Например, чтобы обнаружить момент возникновения ошибки, см. функцию «hg bisect».
Pzz>>>вам нужна система бакапов, а не сорс контрол.
С таким же успехом я могу сказать, что вам, судя по всему, нужна расшаренная папка, а не сорс контрол.
Pzz>Если вы коммитите в сорс контрол с целью не потерять, вы используете его в качестве бакапа.
Я коммичу с разными целями, которые иногда вступают в противоречие. Суть этого противоречия я изложил выше. Для решения этих противоречий в системах контроля версий предусмотрен механизм ветвления. Я не понимаю, почему вы так рьяно оспариваете его необходимость.
Pzz>Сорс контрол, конечно, обладает кроме всего прочего функцией бакапа, но это далеко не самое важное его свойство и даже не одно из основных.
Ну да, бэкап не основное, история не основное, ветвление не нужно — вам точно больше подойдёт расшаренная папка. (Прочувствовали всю бестолковость подобного рода импликаций?)
Pzz>Если у вас поход в туалет требует сложного 20-минутного ритуала, это бюрократия. Однако если туалет вовсе закрыть, все будут хотеть его обратно. Не потому, что заскучают по бюрократии, а потому, что совсем без туалета еще хуже.
Туалет-то всегда открыт, только он может быть грязным и зловонным. Скучают-то по чистоте и уюту.
Pzz>Все хорошо вмеру. Если рутиный коммит предполагает двухчасовые прогоны теста, у вас проблема: никто не захочет делать рутиные коммиты.
Ни в коем случае, рутинный коммит делается в свою изолированную ветку, быстро и надёжно, как автомат Калашникова. В том и соль.
Pzz>Это вам тестеры не нужны, вы их функцию пытаетесь переложить на разработчиков.
Чего? У меня начинают закрадываться смутные сомнения. Скажите, что такое модульные тесты? Кем они пишутся, для кого?
Pzz>Советую еще выдать разработчикам веник и тряпочку, тогда и уборщицы станут не нужны :-)
Так ведь это в вашем мире время разработчика не ценится. Он должен проверять, что коллега не забыл добавить файл в репозиторий (коллега не сможет отловить такую ошибку локально, в его рабочей копии всё на месте). Должен проверять, что регрессионные тесты проходят, что нет битых ссылок на библиотеки (работающих в окружении коллеги). Можно и тряпочку с веником ему заодно дать, программисты ж многопрофильные.
В моём мире — всё что может делать автоматика, лучше ей и доверить. Программист пусть свободное время на зарядку потратит.
по непрерывной интеграции. Транк в любой момент времени должен проходить перечисленные там проверки, это его инвариант.
"Должен проходить перечисленные там проверки" это как-то круто. Имеет смысл оценивать результаты билда с некоторой градацией. Напрмиер билды, которые не прошли проверки Stylecop — в релиз не пускать, но тестерам на ручное тестирование отдать можно.
Здравствуйте, Mr.Cat, Вы писали:
Q>>Под частой синхронизацией подразумевается частое чтение из транка, а не частое его изменение. MC>Вполне очевидно, что читать транк чаще, чем он меняется, невозможно. Поэтому высокая частота вливания из транка в бранчи подразумевает высокую частоту обратного процесса. В итоге, на мой взгляд, суперстабильный транк подходит для обмена изменениями только между супернезависимыми командами разработчиков.
Никто не отменял бранчи для обмена изменениями. У них могут быть более мягкие условия по отношению к стабильности.
Бранчи — они ж не только для изоляции, они ж ещё для коллаборации :)
Здравствуйте, Qbit86, Вы писали:
Q>Имею в виду, что в приведённом тобой примере политика бранчевания работает как минимум не хуже, а по совокупности всех юз-кейзов — лучше, чем работа только в транке.
Ну дык, я и не утверждал, что что-то лучше, а что-то хуже. Просто у каждого подхода есть какие-то "кейзы", которые доставляют больше хлопот разработчикам. И я всего лишь хочу показать, что в случае разработки в бранчах, когда транк объявляется супер-стабильным, т.е. когда транк не только должен компилироваться, но и проходить все тесты — такой проблемой будет слияние в транк двух разъехавшихся веток. И не принципиально, в какой момент это обнаружится: при втором коммите бранч2->транк, или при синхронизации транк(с влитым бранч1)->бранч2. Проблема в том, что из-за жёстких требований к транку коммиты в него будут очень большими и происходить достаточно редко. А раз так, то сколько ни синхронизируй другие бранчи с транком — очень часто будут возникать серьёзные конфликты.
И единственным выходом я вижу снятие ограничения на стабильность транка.
F>>>>ЗЫ. В случае разработки в транке такая ситуация разруливается автоматически — кто первый закоммитил — того и тапки.
Q>При branchy development синхронизация разработчиков тоже происходит через транк (только это не коммит в транк, а вливание ветви в транк). По тому же принципу приоритета тапок.
Да, но как я написал выше, вопрос в частоте синхронизации.
F>>Тут фишка в том, сколько человек и на каком уровне должны продумывать такие изменения. Если требуется добавить дополнительный метод в класс или аргумент к методу, то это не обязательно требует участия Самого Главного Архитектора.
Q>Упомянутое изначально добавление метода в интерфейс — требует, потому что это ломающее изменение. Код клиента твоего API перестанет компилироваться, если ты добавишь метод в интерфейс. И это безотносительно всяких систем контроля версий.
Компилироваться-то перестанет, но очень часто может оказаться так, что другие группы ничего не имеют против таких изменений и с лёгкостью их включили бы в свои бранчи, если это произошло бы на раннем этапе. Если бы разработка велась в транке, то такая серьёзная операция как изменение интерфесов могла бы пройти абсолютно безболезненно для большинства разработчиков. В случае разработки только в бранчах для синхронизации второго бранча с транком с большой вероятностью потребуется гораздо больше телодвижений, поскольку расхождение произошло довольно давно.
F>>А ещё — сколько человек должны заниматься интеграцией изменений. При разработке в транке нет необходимости в специальной роли "интегратор в транк". (Я не утверждаю, что это обязательно хорошо, но что это проще — да)
Q>Как правило, разработчик фичи и должен заниматься вливанием своей feature branch в транк. Ни о каком «интеграторе в транк» (в обсуждаемом простом случае) речи не идёт. Честно говоря, создаётся впечатления, что ты никогда не создавал ветки в Svn, и просто теоретизируешь чисто умозрительно.
Увы, за последний год я насоздавал кучу веток именно в svn.
Q>Ок, объясню. При коммите рабочей папки в транк ты _не_ разруливаешь конфликты. При вливании рабочей ветки в транк ты _не_ разруливаешь конфликты. Ты разруливаешь конфликты внутри рабочей папки при апдейте из транка. Ты разруливаешь конфликты в пределах рабочей ветки при односторонне направленной синхронизации с транком. В момент, когда ты готов влить ветвь в транк, твоя ветвь фактически содержит все наработки из транка плюс твои изолированные изменения. На момент вливания ветки в транк все конфликты уже разрешены.
Объясняю на пальцах. Вот пусть у тебя в какой-то момент времени от транка отвели новый бранч и trunk@12345 совпадает с branch@12345. Через какое-то время тебе надо закоммитить изменение, сделанные в бранче, в транк. В идеале это было бы как-то так:
svn merge -r 12345:12389 svnURL/branch localPATHtrunk
svn ci localPATHtrunk
Но, понятное дело, всплывут конфликты. Ты (вернее, теория разработки в бранчах) предлагаешь их разрешать при постоянной синхронизации trunk->branch, т.е. как-то так:
svn merge -r 12345:12389 svnURL/trunk localPATHbranch
svn ci localPATHbranch
svn merge -r 12345:12390 svnURL/branch localPATHtrunk
svn ci localPATHtrunk
Это всё понятно, и даже работает до какого-то уровня. Проблемы будут, если у тебя несколько десятков активных бранчей, и несколько сот человек активно в них коммитят. И чем больше — тем сильнее будет смещаться соотношение собственно времени разработки ко времени разрешения конфликтов при синхронизации с транком — к этому самому разрешению конфликтов. Это довольно неэффективно, при этом множество людей в своих бранчах будут заниматься одной и той же работой.
Q>Ну и? Конфликты — большие или маленькие — это объективная реальность, а не исключительная ситуация. Возможность конфликтов учтена во всех системах контроля версий. Вот только решать эти конфликты гораздо безопаснее в «чистой» рабочей копии изолированной ветки, чем в незакоммиченной рабочей копии, как это приходится делать при trunk only разработке.
Безопасней — да, наверное. Только почему нельзя закоммитить рабочую копию? Если вместо требования, чтобы транк всегда собирался и проходил все тесты, поставить более слабое — например, чтобы отдельный коммит не ломал сборку/тесты больше чем на сутки — и в течении этого времени он обязательно был исправлен.
Q>Количество же конфликтов, объём изменений и частота мерджей от этого не зависит.
Вот имхо зависят. Но я не претендую на объективное знание, у меня, действительно, не так много опыта — где-то год только активно этим занимаюсь.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, frogkiller, Вы писали:
F>Что тебе не нравится в модели: отвели бранч — какое-то время его стабилизировали — релиз — готовят новый бранч?
Мне ненравится следующее: F>При этом транк иногда может находиться в нерабочем состоянии.
Точнее — «почти всегда».
Мне хочется быть уверенным, что приходящие changeset'ы качественны. Не идеальны и безошибочны, а минимально корректны в терминах, обозначенных выше: код собирается (т.е. найдены все пререквизиты для сборки, не осталось незакоммиченных файлов), проходят тесты, проходят инспекцию бинарного и исходного кода (нет опечаток в идентификаторах, не забыли подписать сборки), в проектах правильно прописаны имена выходных dll-ек (Контора.Проект.*.dll), etc.
Я хочу быть уверенным, что если после апдейта возникнут проблемы с этой базовой валидацией, то это мои проблемы (которые я могу исправить), а не чужие недоделки (которые я исправить не могу, и вынужден ждать, пока автор доделает).
Я хочу, чтобы эту минимальную корректность проверяла автоматика, а не «Эй, Вась, а ты не забыл закоммитить файл MyNewClass.cs?» Etc, etc, etc.
Здравствуйте, Qbit86, Вы писали: Q>Потому что SVN-сервер не пропустит! Он потребует сделать предварительный апдейт. И при этом придётся сделать merge и resolve conflicts. И всё это — «наживую», в «красной» рабочей папке, малейшая ошибка чревата безвозвратной потерей локальных изменений.
Вот честно. У меня ни разу не было проблем при апдейте.
Q>квази-транк со смягчёнными (в любой степени) требованиями.
Мы пробовали. В итоге в мегастабильном транке необходимость отпала, и квазитранк стал обычным транком.
Здравствуйте, Miroff, Вы писали:
Q>>Это не управляемость. Это лишние, внешние, искусственные ограничения — учитывать ещё и гранулярность коммитов.
M>Это именно управляемость. Чем меньше задача, там легче ее оценить, запланировать, сделать и протестировать. В случае достаточно мелкой гранулярности (<8 часов на задачу) конфликтов при коммите вообще не возникает.
Так ведь если задача занимает 8 часов, я обязательно захочу закоммитить промежуточные результаты раз пять, пока её сделаю. Создать точки отката перед рисковыми рефакторингами, etc.
Здравствуйте, Qbit86, Вы писали:
MC>>Давай представим гипотетическую ситуацию. В транке есть критичный баг (допустим, он мешает тестировщикам что-нить там тестировать). Девелопер его зафиксил, но не задокументировал свой код, и в процессе фикса стала невалидной пара тестов. Ты считаешь, что прежде, чем закоммитить фикс, девелопер должен удовлетворить все твои проверки?
Q>Можно временно отключить какое-то подмножество проверок от какого-то конкретного проекта. В любом случае, поведением по умолчанию будет проверка всеми разумными средствами, и лишь в каких-то редких случаях нужно делать исключения. А не наоборот. Как у безопасников: вайт-листы (запрещать всем, кроме некоторых допущенных) предпочтительнее блэк-листов (разрешать всем, кроме некоторых забаненных).
Не надо все делить на "черное" и "белое". В некоторых случаях непрохождение некоторых проверок не является критичным (например надо релизнуть в срок). Тем не менее надо постоянно стремиться чтобы все проверки проходились.
Pzz>>Сорс контрол, конечно, обладает кроме всего прочего функцией бакапа, но это далеко не самое важное его свойство и даже не одно из основных.
Q>Ну да, бэкап не основное, история не основное, ветвление не нужно — вам точно больше подойдёт расшаренная папка. (Прочувствовали всю бестолковость подобного рода импликаций?)
Бэкап ортогонален SCM. Это совершенно разные задачи и уровни оперирования данными.
Если на винте с SCM умрет (по физическим/программным и т.п. причинам) некоторое кол-во секторов, то весь сорс-контрол накроется медным тазом, если бэкапов не было. Уповать на то, что "у девелоперов есть локальные копии" — не панацея по многим причинам (какую из них считать самой истинной, откуда выцарапывать историю в случае централизованного репозитория и т.п.).
Q>В моём мире — всё что может делать автоматика, лучше ей и доверить. Программист пусть свободное время на зарядку потратит.
Здравствуйте, Аноним, Вы писали: А>"у девелоперов есть локальные копии" — не панацея по многим причинам (какую из них считать самой истинной, откуда выцарапывать историю в случае централизованного репозитория и т.п.).
Про локальные копии обычно упоминают в контексте dvcs. Там с историей все в порядке. И абсолютно не важно, какую локальную копию положить на новый центральный сервер в случае смерти старого.
В каких случаях требуется создание отдельной ветви в репозитории?
Встречал разные рекомендации, например:
• Rule 1: The trunk branch must compile and pass regression tests at all times.
• Rule 2: A single commit must represent an entire changeset, and must not be so large to discourage peer-review.
• Rule 3: If rules 1 and 2 are in conflict, create a private branch.
Или:
• Always maintain a private branch for each developer or change.
Или:
• branches for maintenance,
• feature development isolation,
• integration,
• golden releases,
• release candidates,
• private workspaces,
• experimentation features,
• and more.
А вы для каких случаев создаёте отдельные ветви? Какой длины? Как часто синхронизируетесь с транком? Создаёте ли отдельный репозиторий (в случае DVCS)? Удаляете ли ветви после вливания в транк? Возникают ли проблемы независимой поддержки параллельных ветвей? Используете ли плагины и расширения системы контроля версий для наглядной визуализации топологии ветвления?
И вопрос, ради которого затевался топик: какие соглашения об именовании ветвей используете? Включаете ли версию, дату, имя разработчика, название фичи? Пробелы, точки, дефисы, CamelCasing? Какие есть naming best bractises?
Здравствуйте, Qbit86, Вы писали:
Q>В каких случаях требуется создание отдельной ветви в репозитории?
Когда страшно в основную ветвь коммитить, но и не коммитить тоже страшно, чтобы не потерять.
Q>И вопрос, ради которого затевался топик: какие соглашения об именовании ветвей используете? Включаете ли версию, дату, имя разработчика, название фичи? Пробелы, точки, дефисы, CamelCasing? Какие есть naming best bractises?
Любая практика хороша если 1) по имени бранча можно понять, что это такое 2) имена используются консистентно
Здравствуйте, Miroff, Вы писали:
M> В клинических случаях приходилось даже держать целую интеграционную команду, которая только и занималась тем что мерджила сотни веток в один продукт.
Хммм.... По твоему, это плохо? Есть релизная ветка, есть десятки разработчиков и под сотню изменений... как, по-твоему, обойтись без выденной команды или хотя бы человека, который бы брал на себя интеграцию?
Кто будет мержить на релизную ветку? Девелоперы? Им делать больше нечего, как сращивать свои изменения с сотней таких же как он?
Я вот работал в такой команде — и именно интегратором. В ситуации, когда одна релизная ветка и десятки единовременных изменений для неё — без интеграторов нельзя обойтись. Используй ты хоть бы даже и DVCS — ситуация будет та же, изменения на релизную ветку должны вноситься централизованным и контролируемым образом, иначе действительно будет бардак в мёржах и в качестве полученного продукта.
Здравствуйте, Qbit86, Вы писали:
M>>После каждого отгруженного релиза создается ветвь со стандартным именем вида release_19.260.17.18327. Если требуется поддержка именно этой версии в эту ветвь вносятся изменения. И сразу же эта ветвь мержится с транком.
Q>При этом же приходится пересоздавать ветвь? В том смысле, что при «reintegrate branch into trunk» ветку надо закрывать, согласно рекомендациям svn-book'а. Если её продолжать, то могут быть проблемы с синхронизацией с транком.
Это личные интимные проблемы svn
Q>Кстати, а почему для этих целей создаётся ветвь, а не тэг? (Впрочем, в Subversion это одно и то же.)
Потому что в процессе тестирования релиза может возникать необходимость фиксить баги в релизной ветке, не прекращая коммитить фичи в транк.
Здравствуйте, Qbit86, Вы писали:
Q>Но ставит крест на стратегии «commit often». Ходишь, как по минному полю; шаг влево, шаг вправо — и локальные изменения утеряны. Например, при апдейте, мерджевании и ошибке в разруливании конфликтов.
Во-первых, не ставит. Разбивайте задачу на мелкие фичи которые можно комиттить. Заодно и управляемость проекта повысится. Во-вторых, современные IDE умеют хранить локальную историю без всяких VCS. В-третьих, разбивайте проект на отдельные независимые модули и проблем с мерджем будет в разы меньше.
Q>При этом же приходится пересоздавать ветвь? В том смысле, что при «reintegrate branch into trunk» ветку надо закрывать, согласно рекомендациям svn-book'а. Если её продолжать, то могут быть проблемы с синхронизацией с транком.
Сугубо проблемы SVN, да. Честно говоря, ни разу не сталкивался.
Q>Кстати, а почему для этих целей создаётся ветвь, а не тэг? (Впрочем, в Subversion это одно и то же.)
Потому что в этот бранч наверняка пойдут изменения, в том числе и локальные фиксы, которые по разным причинам не должны попасть в транк.
Q>По какому принципу строится номер 19.260.17.18327? Он генерируется автоматически или прописывается руками согласно какому-то соглашению?
Банальный номер версии. major.minor.hotfix.build Интересует как номера версиям назначать?
Здравствуйте, Miroff, Вы писали:
Q>>Но ставит крест на стратегии «commit often». Ходишь, как по минному полю; шаг влево, шаг вправо — и локальные изменения утеряны. Например, при апдейте, мерджевании и ошибке в разруливании конфликтов.
M>Во-первых, не ставит. Разбивайте задачу на мелкие фичи которые можно комиттить.
Не-не-не, так нельзя. «Коммит» выполняет функции кнопки «Save» в редакторах. Она всегда должна быть доступна, причём быстро, сохранение не должно быть многоэтапным. Сделал коммит, и ушёл домой. Сделал коммит, и приступаешь к рискованным операциям в рабочей папке. Сделал коммит — и спишь спокойно.
Но в случае работы в транке, «Коммит» оказывается перегруженным, он выполняет ещё и функцию publishing'а кода. Со всеми вытекающими. Даже в случаях «мелких фич» быстрый комит уже сделать нельзя. Приходится делать апдейт, мерджить, разруливать конфликты — высокий риск потери незакоммиченных («несохранённых») данных. Если коммит прошёл гладко, то всё равно надо дожидаться отклика CI-сервера, прогона тестов, инспекции кода.
Быстрые коммиты становятся невозможны.
M>Заодно и управляемость проекта повысится.
Это не управляемость. Это лишние, внешние, искусственные ограничения — учитывать ещё и гранулярность коммитов.
M>Во-вторых, современные IDE умеют хранить локальную историю без всяких VCS.
Как правило, эта история неглубока. Плюс пока что IDE не научились запоминать историю модификации файловой иерархии. На то есть системы контроля версий.
Q>>По какому принципу строится номер 19.260.17.18327? Он генерируется автоматически или прописывается руками согласно какому-то соглашению?
M>Банальный номер версии. major.minor.hotfix.build Интересует как номера версиям назначать?
Да, если не сложно. Это, наверное, ортогонально топику, но тем не менее.
Здравствуйте, Qbit86, Вы писали:
Q>Не-не-не, так нельзя. «Коммит» выполняет функции кнопки «Save» в редакторах. Она всегда должна быть доступна, причём быстро, сохранение не должно быть многоэтапным. Сделал коммит, и ушёл домой. Сделал коммит, и приступаешь к рискованным операциям в рабочей папке. Сделал коммит — и спишь спокойно.
Ну все-таки не совсем. Коммит должен вносить осмысленные изменения в код. Не "доработал до вечера и пошел спать", а "сделал фичу XXX" или "починил багу YYY". Иначе вы используете систему контроля версий просто в качестве бакапа, и не имеете осмысленной истории изменений.
Q>Но в случае работы в транке, «Коммит» оказывается перегруженным, он выполняет ещё и функцию publishing'а кода. Со всеми вытекающими. Даже в случаях «мелких фич» быстрый комит уже сделать нельзя. Приходится делать апдейт, мерджить, разруливать конфликты — высокий риск потери незакоммиченных («несохранённых») данных. Если коммит прошёл гладко, то всё равно надо дожидаться отклика CI-сервера, прогона тестов, инспекции кода.
Это значит, что у вас слишком много бюрократии в текущей ветке. Разработчики должны свободно коммитить в текущую ветку при условии, что они предпринимают разумное количество усилий не сломать программу. Т.е., как минимум, перед коммитом надо убедиться в том, что программа собирается, и если изменения затрагивают уже работающий код, хоть слегка его оттестировать.
Здравствуйте, Qbit86, Вы писали:
Q>В изолированной ветке разработчика бюрократии нет, она прикручена только к транку. Но при желании допустимо прикрутить бюрократию к какой-нибудь feature branch. И это называется не бюрократия, а планка качества.
А расскажи тогда, как при такой концепции разруливается ситуация исключающих друг друга изменений одних интерфейсов в двух бранчах? Вот, например, есть у тебя 5-6 тесно связанных проектов (и в каждом — несколько поддерживаемых версий), использующих несколько десятков общих библиотек. И вот в двух проектах в head'е branch'а в интерфейсы одной (а лучше — двух-трёх) библиотек вностятся противоречащие друг другу изменения. И там и там в итоге имеется нехилый профит в функциональности — все довольны... до момента, когда это всё надо слить в trunk.
ЗЫ. В случае разработки в транке такая ситуация разруливается автоматически — кто первый закоммитил — того и тапки. Причём в 99% случаев такой конфликт обнаружится на раннем этапе — при первой же попытке коммита второго изменения.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, Qbit86, Вы писали: Q>Не-не-не, так нельзя. «Коммит» выполняет функции кнопки «Save» в редакторах. Она всегда должна быть доступна, причём быстро, сохранение не должно быть многоэтапным. Сделал коммит, и ушёл домой. Сделал коммит, и приступаешь к рискованным операциям в рабочей папке. Сделал коммит — и спишь спокойно.
Ну да, по идее, как-то так, поэтому когда делать коммит в ветку становится опасно, все необходимые разработчики переезжают в отдельную. Получается, что с веткой ассоциируется некий ожидаемый уровень качества.
Q>Но в случае работы в транке, «Коммит» оказывается перегруженным, он выполняет ещё и функцию publishing'а кода.
Ну если в ветке работают несколько разработчиков, то паблишинг все равно имеет место же.
Q>Со всеми вытекающими. Даже в случаях «мелких фич» быстрый комит уже сделать нельзя. Приходится делать апдейт, мерджить, разруливать конфликты — высокий риск потери незакоммиченных («несохранённых») данных. Если коммит прошёл гладко, то всё равно надо дожидаться отклика CI-сервера, прогона тестов, инспекции кода.
Тут, полагаю, опять же играет роль ожидаемый уровень качества.
Здравствуйте, Mr.Cat, Вы писали:
Q>>Но в случае работы в транке, «Коммит» оказывается перегруженным, он выполняет ещё и функцию publishing'а кода. MC>Ну если в ветке работают несколько разработчиков, то паблишинг все равно имеет место же.
Ветки могут использоваться как с целью sharing, так и с целью isolation. Т.е. если в ветке работают несколько разработчиков (feature branch) и возникают проблемы, то всегда можно создать подветки, изолирующие каждого разработчика (workspace branch). Причём изолируют в одну сторону: изменения из родительской ветки в дочернюю должны сливаться как можно чаще, а обратно — по достижению «полноты и непротиворечивости». Разумеется, это всё сложновато, ещё сложнее физически запретить одному разработчику апдейтить изолированную ветку другого. Не знаю даже, можно ли в Subversion раздавать разные права на разные подветки файловой иерархии (а бранчи в Svn являются не более чем ветками в файловой иерархии).
Это как раз является одной из причин, по которым я агитирую свою контору на миграцию с Subversion на Mercurial. Там политика бранчевания может использовать два механизма ветвления — клоны репозитория и именованные бранчи.
MC>Тут, полагаю, опять же играет роль ожидаемый уровень качества.
Уровень качества высокий :) Недавно поднимал рядом ветку
Здравствуйте, Pzz.
Q>>«Сделанная фича» может быть на разных уровнях готовности. Между «собирается и вроде как работает» и «вычищена так, что FxCop носа не подточит» может пролегать много времени. Запрет не коммит до выполнение этих задач — это как запрет автору статьи нажимать Save в Word'е, пока текст не прочитает корректор. Вы предлагаете, перед уходом работы не сохранять рабочую копию? Я не хочу так рисковать дневными наработками.
Pzz>Я предлагаю писать в сорс контрол тогда и только тогда, когда вы можете выразить суть изменения осмысленной записью в логе.
1) Предположим, я могу выразить суть изменения осмысленной записью в логе, например: «Для задачи A выполнены подзадачи A1, A2, A3», и, закономерно, хочу сохранить историю своей работы. 2) Но к концу дня подзадачи A4, A5, A6 ещё не сделаны, я не хочу публиковать фрагменты недоделанной задачи A, так как она помешает другим. Из вашего критерия и из (1) следует, что коммитить надо. Из (2) следует, что коммитить надо не в транк (или общую ветку). Ч.т.д.
Pzz>А если вы боитесь потерять файлы...
Я боюсь потерять не только файлы, но и историю их изменений.
Pzz>вам нужна система бакапов, а не сорс контрол.
0_о Вы это всерьёз?
Pzz>Если у вас планка качества поднята столь высоко, что постоянно мешает работать, это не планка качества, а бюрократия.
Она не мешает работать.
Из-за переезда на другой сервер какое-то время работали без «бюрократии». Спасибо, но все хотят обратно.
Pzz>Я очень рекомендую доверять разрабочикам коммитить в общий сорс контрол, а всякие там code review делать в режиме постмодерирования.
Доверяй, но проверяй. И некоторые проверки кода автоматика делает гораздо эффективнее, чем человек.
Pzz>Осознание того факта, что ошибка разработчика станет проблемой для многих людей, очень повышает уровень ответственности в коллективе и способствует профессиональному росту ваших людей (кроме очень редких исключений, но от тех, кто не хочеть взрослеть, надо постепенно избавляться).
Да вам и тестеры не нужны! У вас разработчики же ответственные. И — да, ремни безопасности придумали трусы.
Q>>«Убеждаться» должна машина. Проверка условий должна выполняться автоматически. Как я могу доверить коллегам не забывать следить за качеством их кода, если я не доверяю даже себе?
Pzz>В этом заключается ваша огромная проблема.
В вашем предложении содержится ложная пресуппозиция.
Pzz>Если вы поручаете что-то людям, вы должны им доверять.
Не поручаю, потому что я не менеджер, я разработчик. И со своей стороны, я не требую, чтобы мне мне доверяли. Я хочу, чтобы проверяли и оспаривали. Это помогает совершенствоваться.
Pzz>...не понимают, что идеальная модель жизни, существующая в вашей голове, воистинну идеальна :-)
Так кто же из нас живёт в стране эльфов? Вы себе противоречите. И снова опираетесь на ложную пресуппозицию.
Pzz>Важно добиваться не того, чтобы не было ошибок (так не бывает). Важно добиваться того, чтобы последствия ошибок быстро исправлялись
Совершенно верно. Поэтому о любой ошибке (из довольно широкого класса), закомиченной в транк, разработчиков быстро оповестит сервер непрерывной интеграции.
Здравствуйте, Qbit86, Вы писали:
Q>1) Предположим, я могу выразить суть изменения осмысленной записью в логе, например: «Для задачи A выполнены подзадачи A1, A2, A3», и, закономерно, хочу сохранить историю своей работы. 2) Но к концу дня подзадачи A4, A5, A6 ещё не сделаны, я не хочу публиковать фрагменты недоделанной задачи A, так как она помешает другим. Из вашего критерия и из (1) следует, что коммитить надо. Из (2) следует, что коммитить надо не в транк (или общую ветку). Ч.т.д.
Я бы провел A1, A2 и А3 отдельными коммитами. Это почти всегда возможно.
Pzz>>А если вы боитесь потерять файлы...
Q>Я боюсь потерять не только файлы, но и историю их изменений.
Ну, если пункты в вашей истории проставлены так же случайно, как люди нажимают кнопку Save, то что в ней ценного?
Pzz>>вам нужна система бакапов, а не сорс контрол.
Q>0_о Вы это всерьёз?
Да, я это всерьез. Если вы коммитите в сорс контрол с целью не потерять, вы используете его в качестве бакапа. Сорс контрол, конечно, обладает кроме всего прочего функцией бакапа, но это далеко не самое важное его свойство и даже не одно из основных.
Pzz>>Если у вас планка качества поднята столь высоко, что постоянно мешает работать, это не планка качества, а бюрократия.
Q>Она не мешает работать. Q>Из-за переезда на другой сервер какое-то время работали без «бюрократии». Спасибо, но все хотят обратно.
Если у вас поход в туалет требует сложного 20-минутного ритуала, это бюрократия. Однако если туалет вовсе закрыть, все будут хотеть его обратно. Не потому, что заскучают по бюрократии, а потому, что совсем без туалета еще хуже.
Pzz>>Я очень рекомендую доверять разрабочикам коммитить в общий сорс контрол, а всякие там code review делать в режиме постмодерирования.
Q>Доверяй, но проверяй. И некоторые проверки кода автоматика делает гораздо эффективнее, чем человек.
Все хорошо вмеру. Если рутиный коммит предполагает двухчасовые прогоны теста, у вас проблема: никто не захочет делать рутиные коммиты.
Pzz>>Осознание того факта, что ошибка разработчика станет проблемой для многих людей, очень повышает уровень ответственности в коллективе и способствует профессиональному росту ваших людей (кроме очень редких исключений, но от тех, кто не хочеть взрослеть, надо постепенно избавляться).
Q>Да вам и тестеры не нужны! У вас разработчики же ответственные. И — да, ремни безопасности придумали трусы.
Это вам тестеры не нужны, вы их функцию пытаетесь переложить на разработчиков. Советую еще выдать разработчикам веник и тряпочку, тогда и уборщицы станут не нужны
Здравствуйте, Qbit86, Вы писали:
Q>Во-первых, не так же случайно (к слову про осмысленный лог). Во-вторых, не хочется терять возможность откатиться назад, причём гранулярность шага не должна быть большой. Например, чтобы обнаружить момент возникновения ошибки, см. функцию «hg bisect».
Если у вас hg, то для ваших целей, вероятно, лучше всего подходит hg mq.
Q>Ну да, бэкап не основное, история не основное, ветвление не нужно — вам точно больше подойдёт расшаренная папка. (Прочувствовали всю бестолковость подобного рода импликаций?)
Здравствуйте, Pzz, Вы писали:
Pzz>Если у вас hg...
У нас пока Svn, но происходит переход на Hg. Именно в связи с этим я и затевал последние пару-тройку топиков. Хочется настроить процесс оптимально, для того и консультируюсь с сообществом.
Pzz>...то для ваших целей, вероятно, лучше всего подходит hg mq.
Про Mq знаю. И то, что я про них знаю, говорит мне, что это почти ортогонально обсуждаемой теме :)
Q>>Ну да, бэкап не основное, история не основное, ветвление не нужно — вам точно больше подойдёт расшаренная папка. (Прочувствовали всю бестолковость подобного рода импликаций?)
Pzz>Ну это вы сейчас со своими фантазиями спорите.
Здравствуйте, Qbit86, Вы писали: Pzz>>Я бы провел A1, A2 и А3 отдельными коммитами. Это почти всегда возможно. Q>Наоборот. Это почти всегда нарушает инварианты транка.
Значит задача А, разбитая на А1..Ан должна уйти в отдельную ветку.
Здравствуйте, Mr.Cat, Вы писали:
Pzz>>>Я бы провел A1, A2 и А3 отдельными коммитами. Это почти всегда возможно. Q>>Наоборот. Это почти всегда нарушает инварианты транка. MC>Значит задача А, разбитая на А1..Ан должна уйти в отдельную ветку. :xz:
Ну да, именно в этом я и пытался убедить Pzz. Чтобы можно было свободно коммитить, и при этом не интерферировать с пользователями транка.
Q>Не-не-не, так нельзя. «Коммит» выполняет функции кнопки «Save» в редакторах. Она всегда должна быть доступна, причём быстро, сохранение не должно быть многоэтапным. Сделал коммит, и ушёл домой. Сделал коммит, и приступаешь к рискованным операциям в рабочей папке. Сделал коммит — и спишь спокойно.
Q>Но в случае работы в транке, «Коммит» оказывается перегруженным, он выполняет ещё и функцию publishing'а кода. Со всеми вытекающими. Даже в случаях «мелких фич» быстрый комит уже сделать нельзя. Приходится делать апдейт, мерджить, разруливать конфликты — высокий риск потери незакоммиченных («несохранённых») данных. Если коммит прошёл гладко, то всё равно надо дожидаться отклика CI-сервера, прогона тестов, инспекции кода.
Меня уже удивляет как люди иногда, задавая вопросы, описывают множество деталей не описывая при этом какой результат надо получить.
Если нужен Save без publish, то вполне можно использовать такую фичу. В TFS она называется shelve, в SVN подобной нету, про другие СКВ не знаю.
Здравствуйте, Qbit86, Вы писали:
F>>ЗЫ. В случае разработки в транке такая ситуация разруливается автоматически — кто первый закоммитил — того и тапки. F>>Причём в 99% случаев такой конфликт обнаружится на раннем этапе — при первой же попытке коммита второго изменения.
Q>Ну и чем, в указанном тобой смысле, отличается «апдейт/коммит» от «синхронизация бранча с транком/синхронизация транка с бранчем»?
Не понял вопроса, поясни, плиз, что ты имеешь ввиду.
F>>А расскажи тогда, как при такой концепции разруливается ситуация исключающих друг друга изменений одних интерфейсов в двух бранчах?
Q>Во-первых, изменения интерфейсов (как наиболее уязвимых частей библиотеки, см. пункт Abstractions) всегда должны продумываться и согласовываться до внесения ломающих изменений. Q>Во-вторых, разруливаются примерно так же, как и при наличии исключающих друг друга изменений в разных рабочих копиях разных разработчиков при работе с единственным транком. В литературе по VCS такая штатная ситуация называется «Конфликт». Странно, что ты не слышал.
Тут фишка в том, сколько человек и на каком уровне должны продумывать такие изменения. Если требуется добавить дополнительный метод в класс или аргумент к методу, то это не обязательно требует участия Самого Главного Архитектора. А ещё — сколько человек должны заниматься интеграцией изменений. При разработке в транке нет необходимости в специальной роли "интегратор в транк". (Я не утверждаю, что это обязательно хорошо, но что это проще — да)
F>>И там и там в итоге имеется нехилый профит в функциональности — все довольны... до момента, когда это всё надо слить в trunk.
Q>Нет. Проблемы всплывут не во время вливания brahch→trunk, а во время синхронизации trunk→brahch. Последнее рекомендуется делать как можно чаще.
Совсем часто синхронизироваться не получится (вернее, делать содержательную синхронизацию) поскольку по твоей концепции изменения в транке должны полностью проходить все тесты. А это значит, что в случае изменения интерфейсов изменение будет довольно большим по объёму (соответственно, чем объёмней изменения, тем они реже).
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, gandjustas, Вы писали: G>Если нужен Save без publish, то вполне можно использовать такую фичу. В TFS она называется shelve, в SVN подобной нету, про другие СКВ не знаю.
В svn можно создать ветку и текущие изменения закоммитить туда.
Здравствуйте, frogkiller, Вы писали:
Q>>Ну и чем, в указанном тобой смысле, отличается «апдейт/коммит» от «синхронизация бранча с транком/синхронизация транка с бранчем»?
F>Не понял вопроса, поясни, плиз, что ты имеешь ввиду.
Имею в виду, что в приведённом тобой примере политика бранчевания работает как минимум не хуже, а по совокупности всех юз-кейзов — лучше, чем работа только в транке.
F>>>ЗЫ. В случае разработки в транке такая ситуация разруливается автоматически — кто первый закоммитил — того и тапки.
При branchy development синхронизация разработчиков тоже происходит через транк (только это не коммит в транк, а вливание ветви в транк). По тому же принципу приоритета тапок.
F>Тут фишка в том, сколько человек и на каком уровне должны продумывать такие изменения. Если требуется добавить дополнительный метод в класс или аргумент к методу, то это не обязательно требует участия Самого Главного Архитектора.
Упомянутое изначально добавление метода в интерфейс — требует, потому что это ломающее изменение. Код клиента твоего API перестанет компилироваться, если ты добавишь метод в интерфейс. И это безотносительно всяких систем контроля версий.
F>А ещё — сколько человек должны заниматься интеграцией изменений. При разработке в транке нет необходимости в специальной роли "интегратор в транк". (Я не утверждаю, что это обязательно хорошо, но что это проще — да)
Как правило, разработчик фичи и должен заниматься вливанием своей feature branch в транк. Ни о каком «интеграторе в транк» (в обсуждаемом простом случае) речи не идёт. Честно говоря, создаётся впечатления, что ты никогда не создавал ветки в Svn, и просто теоретизируешь чисто умозрительно. Ок, объясню. При коммите рабочей папки в транк ты _не_ разруливаешь конфликты. При вливании рабочей ветки в транк ты _не_ разруливаешь конфликты. Ты разруливаешь конфликты внутри рабочей папки при апдейте из транка. Ты разруливаешь конфликты в пределах рабочей ветки при односторонне направленной синхронизации с транком. В момент, когда ты готов влить ветвь в транк, твоя ветвь фактически содержит все наработки из транка плюс твои изолированные изменения. На момент вливания ветки в транк все конфликты уже разрешены.
F>>>И там и там в итоге имеется нехилый профит в функциональности — все довольны... до момента, когда это всё надо слить в trunk.
Q>>Нет. Проблемы всплывут не во время вливания brahch→trunk, а во время синхронизации trunk→brahch. Последнее рекомендуется делать как можно чаще.
F>Совсем часто синхронизироваться не получится (вернее, делать содержательную синхронизацию) поскольку по твоей концепции изменения в транке должны полностью проходить все тесты.
Ещё раз. Если я синхронизирую свой бранч с транком — вливаю (как можно чаще) чьи-то изменения из транка в свой бранч — как я при этом нарушу прохождение транком тестов? Под частой синхронизацией подразумевается частое чтение из транка, а не частое его изменение.
F>А это значит, что в случае изменения интерфейсов изменение будет довольно большим по объёму (соответственно, чем объёмней изменения, тем они реже).
Ну и? Конфликты — большие или маленькие — это объективная реальность, а не исключительная ситуация. Возможность конфликтов учтена во всех системах контроля версий. Вот только решать эти конфликты гораздо безопаснее в «чистой» рабочей копии изолированной ветки, чем в незакоммиченной рабочей копии, как это приходится делать при trunk only разработке. Количество же конфликтов, объём изменений и частота мерджей от этого не зависит.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, gandjustas, Вы писали: G>>Если нужен Save без publish, то вполне можно использовать такую фичу. В TFS она называется shelve, в SVN подобной нету, про другие СКВ не знаю. MC>В svn можно создать ветку и текущие изменения закоммитить туда.
Только появляется геморрой со свитчем веток, их именованием и тому подобным. Это уже не работает как кнопка Save.
Здравствуйте, gandjustas, Вы писали: G>Только появляется геморрой со свитчем веток, их именованием и тому подобным. Это уже не работает как кнопка Save.
Ну не такой уж геморрой. Сделал ветку, свитчнулся, закоммитил. Имя можно выбрать любое, все равно это получается твоя приватная ветка.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Mr.Cat, Вы писали:
Q>>>Под частой синхронизацией подразумевается частое чтение из транка, а не частое его изменение. MC>>Вполне очевидно, что читать транк чаще, чем он меняется, невозможно. Поэтому высокая частота вливания из транка в бранчи подразумевает высокую частоту обратного процесса. В итоге, на мой взгляд, суперстабильный транк подходит для обмена изменениями только между супернезависимыми командами разработчиков.
Q>Никто не отменял бранчи для обмена изменениями. У них могут быть более мягкие условия по отношению к стабильности.
Q>Бранчи — они ж не только для изоляции, они ж ещё для коллаборации
Вернее так: их можно использовать для коллаборации, но это очень неудобно.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, gandjustas, Вы писали: G>>Только появляется геморрой со свитчем веток, их именованием и тому подобным. Это уже не работает как кнопка Save. MC>Ну не такой уж геморрой. Сделал ветку, свитчнулся, закоммитил. Имя можно выбрать любое, все равно это получается твоя приватная ветка.
Да ну.
С Shelve:
Работа -> shelve -> [unshelve] -> работа -> update из транка -> shelve -> [unshelve] -> работа -> update из транка -> commit
Для отдельных веток надо делать swith, merge туда-сюда, потом грохать ветку. Следить за адресами чтобы не было коллизий.
Хотя еще зависит от branching strategy, в случае как с open source вообще делается ветка на любое изменение, но для централизованного проекта это очень большой оверхед по мержингу.
Здравствуйте, gandjustas, Вы писали:
Q>>Никто не отменял бранчи для обмена изменениями. У них могут быть более мягкие условия по отношению к стабильности.
Q>>Бранчи — они ж не только для изоляции, они ж ещё для коллаборации :)
G>Вернее так: их можно использовать для коллаборации, но это очень неудобно.
Здравствуйте, Qbit86, Вы писали:
Q>Упомянутое изначально добавление метода в интерфейс — требует, потому что это ломающее изменение. Код клиента твоего API перестанет компилироваться, если ты добавишь метод в интерфейс. И это безотносительно всяких систем контроля версий.
???
Изменение и удаление метода — ломающее изменение. Несовместимое изменение семантики метода — тоже ломающее изменение. Но почему добавление метода — ломающее изменение?
Здравствуйте, gandjustas, Вы писали:
Q>>Бранчи — они ж не только для изоляции, они ж ещё для коллаборации
G>Вернее так: их можно использовать для коллаборации, но это очень неудобно.
Ну тогда такой вопрос — что в системе контроля версий для коллаборации удобнее, чем ветки?
Вводная информация: проект с 30-40 разработчиками в одной команде (одна компания) и с сотней разработчиков в общей команде, разбросанной по всему миру (большая корпорация с несколькими контракторами).
Здравствуйте, Pzz, Вы писали:
Pzz>Изменение и удаление метода — ломающее изменение. Несовместимое изменение семантики метода — тоже ломающее изменение. Но почему добавление метода — ломающее изменение?
Потому что клиентские реализации твоего интерфейса не имплементируют новый метод. У клиентов после обновления версии вашей библиотеки будут многочисленные ошибки компиляции: «'SomeCustomersClass' does not implement interface member 'YourInterface.NewFunction()'». Абстрактные классы в этом отношении более гибкие.
Это касалось .NET. В C++ аналогом будет возникновение ошибки при создании экземпляра класса: «'SomeCustomersClass' : cannot instantiate abstract class».
Здравствуйте, Aquary, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
Q>>>Бранчи — они ж не только для изоляции, они ж ещё для коллаборации
G>>Вернее так: их можно использовать для коллаборации, но это очень неудобно.
A>Ну тогда такой вопрос — что в системе контроля версий для коллаборации удобнее, чем ветки?
Смотря в какой.
Большинство СКВ не поддерживает ничего кроме веток, в таких системах естественно только ветки и используются для всего.
В других системах есть другие возвожности сохраненения изменений, кроме веток, рассчитанные на определенные сценарии работы. Они определенно удобнее веток будут для этих сценариев.
A>Вводная информация: проект с 30-40 разработчиками в одной команде (одна компания) и с сотней разработчиков в общей команде, разбросанной по всему миру (большая корпорация с несколькими контракторами).
Смотря какая СКВ и какой проект.
Существует несколько branching strategies, которые фактически отличаются тем насколько часто надо создавать ветки. Большое количество веток ведет к оверхеду по слиянию веток, но делает разработку фич отдельными командами или людьми более независимой.
Общая формула — частота создания веток обратно пропорциональна уровню централизованности разарботки.
Здравствуйте, Aquary, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>В других системах есть другие возвожности сохраненения изменений, кроме веток, рассчитанные на определенные сценарии работы. Они определенно удобнее веток будут для этих сценариев.
A>Например? Shelves? Они не для коллаборации (АКА взаимодействия). Они для временного сохранения изменений без образования бранча, для демонстрации своих результатов без образования бранча. По сути это — кастрированный бранч.
Да, именно это и нужно — save без publish.
A>Какие ещё способы взаимодействия через VCS, но без бранчей ты знаешь?
Я не спец по разным СКВ, видел только CVS, SVN, TFS и немного git.
A>>>Вводная информация: проект с 30-40 разработчиками в одной команде (одна компания) и с сотней разработчиков в общей команде, разбросанной по всему миру (большая корпорация с несколькими контракторами). G>>Смотря какая СКВ и какой проект.
A>Приведи свой пример — ты сказал, что есть способы безболезненного взаимодействия через VCS, но без бранчей. Назови свой пример подобного взаимодействия с указанными условиями.
Еще раз: сильно зависит от СКВ, политики и проекта.
G>>Существует несколько branching strategies, которые фактически отличаются тем насколько часто надо создавать ветки.
A>Ты сказал branching strategies. Т.е. ветвление таки должно быть?
Это уже по теме поста.
G>>Большое количество веток ведет к оверхеду по слиянию веток, но делает разработку фич отдельными командами или людьми более независимой.
A>В чем заключается оверхед? В том, что надо мержить с веток на главную линейку? Ты хоть какие shelves используй — без слияния девелоперских изменений не обойдешься.
Shelve — хороший вариант для одного — двух девелоперов, для взаимодействия команд может таки понадобиться плодить бранчи, других способов я пока не знаю.
G>>Общая формула — частота создания веток обратно пропорциональна уровню централизованности разарботки.
A>Неверно. Чем больше централизована разработка, тем больше необходимость ветвления для отдельного разработчика.
Счегобы?
A>Представь единый центральный trunk (ситуация центральнее некуда), десяток разработчиков. Ты им предлагаешь жить без веток? Допустим.
Да, у меня именно так и работают.
A>Типа договариваются между собой насчет регулярных мержей и т.п. (глюк, но допустим.)
Коммит без апдейта не сделаешь.
A>Появляется ещё десяток разработчиков ... Твои действия?
Тоже все на транк, и нииппет.
A>Разумеется, ты их всех хором отправляешь на отдельные ветки или shelve'ы (смотря что больше принято в твоей VCS).
Зачем?
A>Получатся — централизованная разработка — много веток.
Не получилось...
A>Повторю — кажущийся оверхед по мержам — ничто по сравнению с бардаком, который получаешь при отсутствии веток.
Бардак устраняется автоматизацией тестирования, статических проверок и прочего, а это очень дисциплинирует команду.
Но в такой ситуации нужно постоянно следить чтобы разработчики не забили йух на ломающиеся былды. В таком случае автоматизация очень помогает, можно автоматом назначать баги за сломанные билды. А потом не давать ЗП пока баги не закрыты
Тут возникает проблема в том что разработчику мужет быть сложно сконцентрироваться на задаче из-за постоянных правок кода из-за изменений транка.
Тогда делается отдельная ветка для него и проблемы мержинга откладваются во времени. Потом приходит час Ч и требуется смержить N веток для нового релиза. Только все разработчики не видели изменения друг друга и тут начинается веселье...
Здравствуйте, Qbit86, Вы писали:
Q>Потому что клиентские реализации твоего интерфейса не имплементируют новый метод. У клиентов после обновления версии вашей библиотеки будут многочисленные ошибки компиляции: «'SomeCustomersClass' does not implement interface member 'YourInterface.NewFunction()'». Абстрактные классы в этом отношении более гибкие.
Ну тогда скорее уж не добавление, а использование.
Абстрактные классы (в C++) в этом плане еще хуже. Добавление виртуального метода ломает ABI.
Здравствуйте, gandjustas, Вы писали:
G>Да, именно это и нужно — save без publish.
Для взаимодействия нужен publish, увы.
A>>Какие ещё способы взаимодействия через VCS, но без бранчей ты знаешь? G>Я не спец по разным СКВ, видел только CVS, SVN, TFS и немного git.
Вопрос был не "какие знаешь" а в каких взаимодействие можно сделать без бранчей?
A>>Ты сказал branching strategies. Т.е. ветвление таки должно быть? G>Это уже по теме поста.
Но ты заявил, что веток вообще надо избегать ибо гемор... Вот про это и были мои возражения.
A>>Представь единый центральный trunk (ситуация центральнее некуда), десяток разработчиков. Ты им предлагаешь жить без веток? Допустим. G>Да, у меня именно так и работают. A>>Типа договариваются между собой насчет регулярных мержей и т.п. (глюк, но допустим.) G>Коммит без апдейта не сделаешь. A>>Появляется ещё десяток разработчиков ... Твои действия? G>Тоже все на транк, и нииппет.
Бардак, что сказать. Кстати, как ты отлаживаешь новые фичи при такой организации? 5 человек пишут новый код, который заработает только при наличии всех 5 изменений, у всех они — по сути в локальных копиях, т.е. взять из системы контроля версий сразу все 5 изменений — нереально без приседаний. Что делать будешь?
С ветками вопрос не стоит — берешь содержимое всех веток, делаешь при необходимости интеграционные ветки (если изменения пересекаются по файлам) — и получаешь срез с новой фичей, но без коммита на бранч.
G>Бардак устраняется автоматизацией тестирования, статических проверок и прочего, а это очень дисциплинирует команду.
Но вся дисциплина держится на том, что каждый у себя локально перед коммитом на транк прогоняет автотесты и т.п.?
G>Тут возникает проблема в том что разработчику мужет быть сложно сконцентрироваться на задаче из-за постоянных правок кода из-за изменений транка. G>Тогда делается отдельная ветка для него и проблемы мержинга откладваются во времени. Потом приходит час Ч и требуется смержить N веток для нового релиза. Только все разработчики не видели изменения друг друга и тут начинается веселье...
Для этого в крупных командах выделяется роль (а иногда и должность) интегратора. Девелоперы дают ему свои ветки (просто указывая ветки или ревизии), и продолжают заниматься тем, что становится более приоритетным. Интегратор же один за одним сращивает изменения (как правило, это происходит автоматом, конфликты составляют небольшой процент), прогоняет автотесты, отдает на руное тестирование и т.п. и далее самостоятельно интегрирует изменения на транк.
Конечно, выделенная роль интегратора подходит только средним и крупным командам. днако мы ведь про них речь и ведем?
Здравствуйте, frogkiller, Вы писали:
Q>>Конфликты — большие или маленькие — это объективная реальность, а не исключительная ситуация. Возможность конфликтов учтена во всех системах контроля версий. Вот только решать эти конфликты гораздо безопаснее в «чистой» рабочей копии изолированной ветки, чем в незакоммиченной рабочей копии, как это приходится делать при trunk only разработке.
F>Безопасней — да, наверное. Только почему нельзя закоммитить рабочую копию?
Потому что SVN-сервер не пропустит! Он потребует сделать предварительный апдейт. И при этом придётся сделать merge и resolve conflicts. И всё это — «наживую», в «красной» рабочей папке, малейшая ошибка чревата безвозвратной потерей локальных изменений.
F>Если вместо требования, чтобы транк всегда собирался и проходил все тесты, поставить более слабое — например, чтобы отдельный коммит не ломал сборку/тесты больше чем на сутки — и в течении этого времени он обязательно был исправлен.
А как такого добиться? Скажем, я за свой коммит могу поручиться — да, всё сломалось, но меньше, чем за сутки, я свои ломающие изменения починю. Вот только транк не станет «чистым», потому что пока я чинил, кто-то внёс новую промежуточную правку, дав честное слово исправить в течении суток. Грубо говоря, мои разрешённые «красные» сутки будут пересекаться с чьими-то ещё, и при достаточно большой команде ось времени будет сплошь покрыта «красными» промежутками.
F>И я всего лишь хочу показать, что в случае разработки в бранчах, когда транк объявляется супер-стабильным, т.е. когда транк не только должен компилироваться, но и проходить все тесты — такой проблемой будет слияние в транк двух разъехавшихся веток.
Представим ситуацию. Два из трёх разработчиков совместно работают над какой-то фичей. Причём: 1) Они хотят обмениваться промежуточными (возможно, нестабильными) результатами, синхронизироваться часто и в обе стороны, чтобы не разьезжаться далеко. 2) Они не хотят интерферировать с третьим разработчиком, и приводить к нестабильности в транке.
В этом случае, они вполне могут ответвить общую ветку фичи, и синхронизировать изменения через неё — будь то синхронизация рабочей копии этой feature branch, или изолированных workspace branch (как и предлагал
bkat). Другими словами, получается эдакий квази-транк со смягчёнными (в любой степени) требованиями.
Это не противоречит стабильности транка.
F>И единственным выходом я вижу снятие ограничения на стабильность транка.
Это приводит к тому, что, в общем случае, ни в один момент времени транк не является стабильным. Показать его заказчику или тестерам нельзя.
F>Компилироваться-то перестанет, но очень часто может оказаться так, что другие группы ничего не имеют против таких изменений и с лёгкостью их включили бы в свои бранчи, если это произошло бы на раннем этапе.
А потом переписывали и переписывали бы код использования интерфейса в соответствии с тем, как автор меняет интерфейс — он ведь и не обещал его устойчивость на время активной с ним работы.
F>Если бы разработка велась в транке, то такая серьёзная операция как изменение интерфесов могла бы пройти абсолютно безболезненно для большинства разработчиков.
Ага, причём несколько раз. Вместо того, чтобы получить окончательную, более-менее устойчивую версию, ничего не зная о промежуточных, «рабочих» (или даже «экспериментальных») версиях.
F>Увы, за последний год я насоздавал кучу веток именно в svn.
Попробуй Mercurial!
F>:) Объясняю на пальцах. Вот пусть у тебя... F>Это всё понятно, и даже работает до какого-то уровня. Проблемы будут, если у тебя несколько десятков активных бранчей, и несколько сот человек активно в них коммитят. И чем больше — тем сильнее будет смещаться соотношение собственно времени разработки ко времени разрешения конфликтов при синхронизации с транком — к этому самому разрешению конфликтов.
Так ведь коммитят-то часто в бранчи, а в транк попадает только то, «что нужно» (условно). Если бы шли частые коммиты в транк, то была бы проблема другого рода: слияния бы приходилось делать чаще, притом сливаться приходилось бы с неустойчивыми версиями, которые завтра устареют, станут deprecated/obsolete, и пересливаться придётся заново.
Фигурирующие в дискуссии «подзадачи» — они же не обязательно обладают свойством аддитивности. Фактически, объём кода при решении задач может оставаться почти неизменным от коммита к коммиту (или даже уменьшаться при рефакторинге). Ну, например, надо реализовать класс с четырьмя функциями Foo, Bar, Baz, Qux. Разработчик делает это в три-четыре коммита: сначала Foo, Bar, Baz, (а Qux пока бросает NotImplementedException); потом выясняется, что в Foo надо передать ещё один аргумент, потом Bar переименовывает в SafeBar, и добавляет ещё функцию-обёртку, потом реализовывает Qux; потом меняет асимптотику метода Baz чтобы выиграть во времени за счёт памяти.
Если делать коммиты в транк, и, не дай бог, кто-то начнёт использовать неустойчивые результаты — то объём действий при слиянии существенно увеличится.
Здравствуйте, Aquary, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Да, именно это и нужно — save без publish.
A>Для взаимодействия нужен publish, увы.
Ну и пусть будет коммит в транк.
Изначальный посыл был — save без publish, это в чистом виде shelve\stash.
Если нужно обеспечить взаимодействие нескольих человек, то тут появляются варианты.
1)Разделить на непересекающиеся задачи и коммитить в транк
2)Выделить ветку на группу, потом мержить в с транком
3)Использовать shelve\stash для передачи изменений между пользователями (работает для 2-3 человек максимум)
A>Но ты заявил, что веток вообще надо избегать ибо гемор... Вот про это и были мои возражения.
Я и сейчас тоже заявлю — избегать создания лишних веток при централизованной разработке.
A>>>Представь единый центральный trunk (ситуация центральнее некуда), десяток разработчиков. Ты им предлагаешь жить без веток? Допустим. G>>Да, у меня именно так и работают. A>>>Типа договариваются между собой насчет регулярных мержей и т.п. (глюк, но допустим.) G>>Коммит без апдейта не сделаешь. A>>>Появляется ещё десяток разработчиков ... Твои действия? G>>Тоже все на транк, и нииппет.
A>Бардак, что сказать.
Где?
A>Кстати, как ты отлаживаешь новые фичи при такой организации?
Отлично отлаживаю.
A>5 человек пишут новый код, который заработает только при наличии всех 5 изменений, у всех они — по сути в локальных копиях, т.е. взять из системы контроля версий сразу все 5 изменений — нереально без приседаний. Что делать будешь?
Это ты сам придумал. Не забывай про commit early, commit often.
A>С ветками вопрос не стоит — берешь содержимое всех веток, делаешь при необходимости интеграционные ветки (если изменения пересекаются по файлам) — и получаешь срез с новой фичей, но без коммита на бранч.
У меня последняя версия в транке, не надо дополнительных действий никаких.
G>>Бардак устраняется автоматизацией тестирования, статических проверок и прочего, а это очень дисциплинирует команду.
A>Но вся дисциплина держится на том, что каждый у себя локально перед коммитом на транк прогоняет автотесты и т.п.?
Может и не прогонять, тогжа билд упадет и человеку все равно придется исправлять.
G>>Тут возникает проблема в том что разработчику мужет быть сложно сконцентрироваться на задаче из-за постоянных правок кода из-за изменений транка. G>>Тогда делается отдельная ветка для него и проблемы мержинга откладваются во времени. Потом приходит час Ч и требуется смержить N веток для нового релиза. Только все разработчики не видели изменения друг друга и тут начинается веселье...
A>Для этого в крупных командах выделяется роль (а иногда и должность) интегратора. Девелоперы дают ему свои ветки (просто указывая ветки или ревизии), и продолжают заниматься тем, что становится более приоритетным. Интегратор же один за одним сращивает изменения (как правило, это происходит автоматом, конфликты составляют небольшой процент), прогоняет автотесты, отдает на руное тестирование и т.п. и далее самостоятельно интегрирует изменения на транк. A>Конечно, выделенная роль интегратора подходит только средним и крупным командам. днако мы ведь про них речь и ведем?
А зачем вообще создавать ветки на каждого разработчика при централизованной разработке?
Ветка на крупную фичу — еще могу понять, но тогда сама команда мержит изменения и проблем почти нет, и должностей интеграторов нет.
Здравствуйте, gandjustas, Вы писали: G>Для отдельных веток надо делать swith, merge туда-сюда, потом грохать ветку. Следить за адресами чтобы не было коллизий. G>Хотя еще зависит от branching strategy, в случае как с open source вообще делается ветка на любое изменение, но для централизованного проекта это очень большой оверхед по мержингу.
Не, ну я согласен, что кнопок больше жать, но про оверхед, бранчинг стратежи и слежение за адресами — эт все-же перебор.
Здравствуйте, Qbit86, Вы писали:
F>>Только почему нельзя закоммитить рабочую копию?
Q>Потому что SVN-сервер не пропустит! Он потребует сделать предварительный апдейт. И при этом придётся сделать merge и resolve conflicts. И всё это — «наживую», в «красной» рабочей папке, малейшая ошибка чревата безвозвратной потерей локальных изменений.
И? ну сделает человек svn up, ну что-то само смерджится, чему-то человек поможет, а чему-то скажет resolve my-full. Закоммитить не проблема — возможной проблемой (для твоего подхода) будет то, что закоммиченное может даже и не собираться, не говоря уже о тестах.
F>>Если вместо требования, чтобы транк всегда собирался и проходил все тесты, поставить более слабое — например, чтобы отдельный коммит не ломал сборку/тесты больше чем на сутки — и в течении этого времени он обязательно был исправлен.
Q>А как такого добиться? Скажем, я за свой коммит могу поручиться — да, всё сломалось, но меньше, чем за сутки, я свои ломающие изменения починю. Вот только транк не станет «чистым», потому что пока я чинил, кто-то внёс новую промежуточную правку, дав честное слово исправить в течении суток. Грубо говоря, мои разрешённые «красные» сутки будут пересекаться с чьими-то ещё, и при достаточно большой команде ось времени будет сплошь покрыта «красными» промежутками.
Это зависит от дисциплины и от разных вспомогательных средств. Например, можно слать письма-напоминалки сломавшему сборку/тест.
Q>В этом случае, они вполне могут ответвить общую ветку фичи, и синхронизировать изменения через неё — будь то синхронизация рабочей копии этой feature branch, или изолированных workspace branch (как и предлагал
bkat). Другими словами, получается эдакий квази-транк со смягчёнными (в любой степени) требованиями. Q>Это не противоречит стабильности транка. F>>И единственным выходом я вижу снятие ограничения на стабильность транка. Q>Это приводит к тому, что, в общем случае, ни в один момент времени транк не является стабильным. Показать его заказчику или тестерам нельзя.
Да, транк становится нестабильным — ну и что с того. Заказчику и тестерам можно показывать специальные стабильные бранчи, которые потом и релизить.
Вот ты приводил пример, как два разработчика обмениваются изменениями, исключив третьего, и создают для этого специальный бранч. А теперь представь, что это не два разработчика, а две команды, человек по 30 в каждой, они делают по сотне коммитов в день, а кроме них есть ещё несколько команд, которые тоже не сидят сложа руки. Тут будет сразу несколько таких обменных бранчей, и они разъедутся очень-очень быстро.
Я понял — всё дело в размере проекта, и насколько активно используются его общие части.
F>>Увы, за последний год я насоздавал кучу веток именно в svn. Q>Попробуй Mercurial!
Ну, это несколько не от меня зависит. А просто так, на поиграться — думаю, я не смогу ощутить, в чём его реальное преимущество перед svn на тестовых проектах из 3-х файлов...
F>> Объясняю на пальцах. Вот пусть у тебя... F>>Это всё понятно, и даже работает до какого-то уровня. Проблемы будут, если у тебя несколько десятков активных бранчей, и несколько сот человек активно в них коммитят. И чем больше — тем сильнее будет смещаться соотношение собственно времени разработки ко времени разрешения конфликтов при синхронизации с транком — к этому самому разрешению конфликтов.
Q>Так ведь коммитят-то часто в бранчи, а в транк попадает только то, «что нужно» (условно). Если бы шли частые коммиты в транк, то была бы проблема другого рода: слияния бы приходилось делать чаще, притом сливаться приходилось бы с неустойчивыми версиями, которые завтра устареют, станут deprecated/obsolete, и пересливаться придётся заново.
Q>Если делать коммиты в транк, и, не дай бог, кто-то начнёт использовать неустойчивые результаты — то объём действий при слиянии существенно увеличится.
Вывод — при разработке в транке не надо часто синхронизировать с ним бранчи. Проще отвести новый бранч и немного допилить до стабильного состояния Ну и более ответственно подходить к моменту отведения бранча.
ЗЫ. Ещё раз — я не говорю, что что-то хорошо, а другое плохо. Всё зависит от контекста.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, Qbit86, Вы писали:
F>>Да, транк становится нестабильным — ну и что с того. Заказчику и тестерам можно показывать специальные стабильные бранчи, которые потом и релизить. Q>Где ж их взять-то, стабильные бранчи? Как поймать момент стабильности транка, чтоб ответвить от него стабильный бранч?
А не обязательно ловить "момент стабильности". Можно какое-то время стабилизировать отведённый бранч — так чтобы проходили желаемые тесты.
Q>Я так понимаю, ты шаг за шагом всё таки склоняешься к необходимости бранчевания.
Не совсем. Какая-то стабильность несомненно нужна, и отдельные feature-бранчи необходимы. Мне только не нравится чрезмерная жётскость в транке.
F>>А теперь представь, что это не два разработчика, а две команды, человек по 30 в каждой, они делают по сотне коммитов в день, а кроме них есть ещё несколько команд, которые тоже не сидят сложа руки. Тут будет сразу несколько таких обменных бранчей, и они разъедутся очень-очень быстро.
Q>А теперь представь, что они одновременно коммитят неконсистентные, промежуточные шаги в транк. Q>Бранчевание, поддержка непротиворечивости и чистоты стабильных веток — это общепринятая практика. Никто так просто не позволит коммитить в стабильные ветки ядра Линукса. Но это не повод не коммитить вообще.
Стабильные ветки — это не транк. Это как раз то, что я пытаюсь тебе описать. Что тебе не нравится в модели: отвели бранч — какое-то время его стабилизировали — релиз — готовят новый бранч? Причём не обязательно эти стадии должны идти строго последовательно (можно отвести следующий бранч во время стабилизации предыдущего). При этом транк иногда может находиться в нерабочем состоянии.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, Aquary, Вы писали:
A>Хммм.... По твоему, это плохо? Есть релизная ветка, есть десятки разработчиков и под сотню изменений... как, по-твоему, обойтись без выденной команды или хотя бы человека, который бы брал на себя интеграцию?
Я не говорю, что это обязательно плохо, проекты бывают разные. Но для меня такой подход это показатель серьезных проблем с организацией кода. Один разработчик никогда не работает над всем проектом целиком. Почти всегда можно разбить проект на несколько независимых модулей с собственной нумерацией версий, независимой сборкой и независимым тестированием. Модули могут взаимодействовать между собой только по явно специфицированным интерфейсам, которые, конечно, придется проверять при тестировании. По тому же принципу можно разбить десятки разработчиков на группы, тогда их коммиты будут вызывать конфликты только внутри группы, а внутри небольшой группы конфликт легко может разрешить сам разработчик. Короче, групповое владение кодом. Никакой общей релизной ветки для всего продукта вообще не потребуется. Для релиза достаточно вытащить стабилизированные версии модулей, собрать в кучу и отдать на тестирование.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, Aquary, Вы писали:
A>>Хммм.... По твоему, это плохо? Есть релизная ветка, есть десятки разработчиков и под сотню изменений... как, по-твоему, обойтись без выденной команды или хотя бы человека, который бы брал на себя интеграцию?
M>Я не говорю, что это обязательно плохо, проекты бывают разные. Но для меня такой подход это показатель серьезных проблем с организацией кода.
По-моему, нельзя судить об организации кода, ни разу его не видев.
M>Один разработчик никогда не работает над всем проектом целиком. Почти всегда можно разбить проект на несколько независимых модулей с собственной нумерацией версий, независимой сборкой и независимым тестированием. Модули могут взаимодействовать между собой только по явно специфицированным интерфейсам, которые, конечно, придется проверять при тестировании. По тому же принципу можно разбить десятки разработчиков на группы, тогда их коммиты будут вызывать конфликты только внутри группы, а внутри небольшой группы конфликт легко может разрешить сам разработчик. Короче, групповое владение кодом.
Не поверишь — но именно так и было сделано. Много компонент в составе большого продукта. Продукт — сотовый телефон. Компоненты — программные слои или же классы приложений. Так вот десятки разработчиков были именно в отдельных компонентах, которые, конечно, были разделены на подкомпоненты с группами поменьше. И даже внутри группы часто работа шла над одними и тем же файлами. Да, было групповое владение кодом, однако каждый сидел на своей ветке для отдельный изменений по отдельным запросам. А интеграторы компоненты собирали изменения вместе от всех групп и из этого делали что-то, что можно было целиком отдать тестерам на прогон комплексного тестирования.
M> Никакой общей релизной ветки для всего продукта вообще не потребуется. Для релиза достаточно вытащить стабилизированные версии модулей, собрать в кучу и отдать на тестирование.
Как обычно, сознание изменено терминологией и принципами SVN... Мы использовали правильную систему контроля версий, где у каждого элемента — своё дерево версий (так сделано практически везде, кроме SVN). И релизная ветка — это ветка, созданная для каждого элемента автоматом.
Думаю, больше рассказывать не буду, а то много получится, тема не про это
В общем, пора, наверное, уже написать мне очередную статью по configuration management и рассказать как наша команда далала подобные вещи.
Здравствуйте, Mr.Cat, Вы писали:
Q>>Потому что SVN-сервер не пропустит! Он потребует сделать предварительный апдейт. И при этом придётся сделать merge и resolve conflicts. И всё это — «наживую», в «красной» рабочей папке, малейшая ошибка чревата безвозвратной потерей локальных изменений. MC>Вот честно. У меня ни разу не было проблем при апдейте.
С этим впору поздравлять!
Q>>квази-транк со смягчёнными (в любой степени) требованиями. MC>Мы пробовали. В итоге в мегастабильном транке необходимость отпала, и квазитранк стал обычным транком.
Здравствуйте, Qbit86, Вы писали: Q>>>квази-транк со смягчёнными (в любой степени) требованиями. MC>>Мы пробовали. В итоге в мегастабильном транке необходимость отпала, и квазитранк стал обычным транком. Q>У вас есть выделенная билд-машина?
Да.
Здравствуйте, Mr.Cat, Вы писали:
MC>>>Мы пробовали. В итоге в мегастабильном транке необходимость отпала, и квазитранк стал обычным транком. Q>>У вас есть выделенная билд-машина? MC>Да.
Что происходит, когда код в рабочей копии билд-машины не собирается? Состояние «последняя сборка провалена» как-то выделено? Разработчики об этом оповещаются автоматически, или должны ручками опрашивать состояние?
Здравствуйте, Qbit86, Вы писали: Q>Состояние «последняя сборка провалена» как-то выделено? Разработчики об этом оповещаются автоматически, или должны ручками опрашивать состояние?
Да, разработчики оповещаются, но проблем с поломанным транком обычно не бывает (а если бывают, то обычно обнаруживаются работающими в транке коллегами при апдейте, а не билд-системой). Но у нас просто размер проекта позволяет перед коммитом убедиться, что все билдится (а билдить все равно приходится — например, чтобы проверить, что баг, над которым идет работа, больше не воспроизводится).
Здравствуйте, Mr.Cat, Вы писали:
Q>>Состояние «последняя сборка провалена» как-то выделено? Разработчики об этом оповещаются автоматически, или должны ручками опрашивать состояние? MC>Да, разработчики оповещаются, но проблем с поломанным транком обычно не бывает (а если бывают, то обычно обнаруживаются работающими в транке коллегами при апдейте, а не билд-системой).
Вот. Мы тоже работали по схеме «проблемы обнаруживаются при апдейте другим разработчиком» (или даже: «Вась, можешь выгрузить и проверить, всё ли собирается?»). Но это контрпродуктивно и опасно (скажем, если на момент обнаружения поломки автора уже нет в офисе, etc). Как только вы придёте к автоматической проверке состояния «билд сломан» (т.е. «должен быть как можно скорее починен, для восстановления инварианта»), это и будет означать «стабильный транк». Пусть проверок вначале мало (только собираемость), но это уже концептуально правильное начало.
MC>Но у нас просто размер проекта позволяет перед коммитом убедиться, что все билдится
А статус файлов «Added» тоже проверяете глазами? Или, скажем, проверяете, что все публичные методы задокментированы? Etc, etc, etc, таких проверок могут быть десятки. Даже при образцовой добросовестности можно что-нибудь упустить.
Здравствуйте, Qbit86, Вы писали: Q>Как только вы придёте к автоматической проверке состояния «билд сломан» (т.е. «должен быть как можно скорее починен, для восстановления инварианта»), это и будет означать «стабильный транк». Пусть проверок вначале мало (только собираемость), но это уже концептуально правильное начало.
По идее, конечно, при коммите надо на сервере делать билд (возможно, проводить какой-то минимальный набор тестов) и сообщать авторам последних изменений, если билд сломался. Но лень, честно говоря.
Q>А статус файлов «Added» тоже проверяете глазами?
Ага.
Q>Или, скажем, проверяете, что все публичные методы задокментированы? Etc, etc, etc, таких проверок могут быть десятки. Даже при образцовой добросовестности можно что-нибудь упустить.
А это и не надо проверять постоянно. Ну что-то там не задокументировано. Ну пара тестов устарела и свалилась. Обычно это не мешает править критичные баги, обмениваться изменениями с другими разработчиками и отдавать версию на ручное тестирование. Эти вещи можно исправлять по ходу работы над другими задачами и по мере возникновения свободного времени. У задач может быть различный приоритет, и я против того, чтобы устраивать бюрократию вокруг задач с заведомо не самым высоким.
Здравствуйте, Mr.Cat, Вы писали:
MC>По идее, конечно, при коммите надо на сервере делать билд (возможно, проводить какой-то минимальный набор тестов) и сообщать авторам последних изменений, если билд сломался. Но лень, честно говоря.
Конечно, лень! Если ты программист, то лень входит в перечень твоих должностных обязанностей. Билд на сервере (где окружение «чище», чем у разработчика; скажем, нет Visual Studio) должна делать автоматика, ей не лень.
Q>>А статус файлов «Added» тоже проверяете глазами? MC>Ага.
Но ведь если что-то упустишь, то фидбэк будет отложенным (до момента, когда ты уже почти ушёл из офиса домой). Свитч контекста опять же, всё такое.
Q>>Или, скажем, проверяете, что все публичные методы задокментированы? Etc, etc, etc, таких проверок могут быть десятки. Даже при образцовой добросовестности можно что-нибудь упустить.
MC>А это и не надо проверять постоянно. Ну что-то там не задокументировано. Ну пара тестов устарела и свалилась. Обычно это не мешает править критичные баги, обмениваться изменениями с другими разработчиками и отдавать версию на ручное тестирование. Эти вещи можно исправлять по ходу работы над другими задачами и по мере возникновения свободного времени. У задач может быть различный приоритет, и я против того, чтобы устраивать бюрократию вокруг задач с заведомо не самым высоким.
Это не бюрократия. Это assistance. Это дисциплина. Это чистоплотность. Как чистить зубы, делать зарядку, обращать внимание на ворнинги компилятора.
Здравствуйте, Qbit86, Вы писали: Q>Это не бюрократия. Это assistance. Это дисциплина. Это чистоплотность. Как чистить зубы, делать зарядку, обращать внимание на ворнинги компилятора.
Либо мы друг друга недопонимаем, либо это та дисциплина, которая вместе с бондажом, садо и мазо. Давай представим гипотетическую ситуацию. В транке есть критичный баг (допустим, он мешает тестировщикам что-нить там тестировать). Девелопер его зафиксил, но не задокументировал свой код, и в процессе фикса стала невалидной пара тестов. Ты считаешь, что прежде, чем закоммитить фикс, девелопер должен удовлетворить все твои проверки?
Здравствуйте, Mr.Cat, Вы писали:
MC>Либо мы друг друга недопонимаем, либо это та дисциплина, которая вместе с бондажом, садо и мазо.
Не, садо-мазо начнётся, если я ещё пару гардов к CI-серверу прикручу :)
MC>Давай представим гипотетическую ситуацию. В транке есть критичный баг (допустим, он мешает тестировщикам что-нить там тестировать). Девелопер его зафиксил, но не задокументировал свой код, и в процессе фикса стала невалидной пара тестов. Ты считаешь, что прежде, чем закоммитить фикс, девелопер должен удовлетворить все твои проверки?
Можно временно отключить какое-то подмножество проверок от какого-то конкретного проекта. В любом случае, поведением по умолчанию будет проверка всеми разумными средствами, и лишь в каких-то редких случаях нужно делать исключения. А не наоборот. Как у безопасников: вайт-листы (запрещать всем, кроме некоторых допущенных) предпочтительнее блэк-листов (разрешать всем, кроме некоторых забаненных).
Здравствуйте, gandjustas, Вы писали:
Q>>Можно временно отключить какое-то подмножество проверок от какого-то конкретного проекта. В любом случае, поведением по умолчанию будет проверка всеми разумными средствами, и лишь в каких-то редких случаях нужно делать исключения. А не наоборот. Как у безопасников: вайт-листы (запрещать всем, кроме некоторых допущенных) предпочтительнее блэк-листов (разрешать всем, кроме некоторых забаненных).
G>Не надо все делить на "черное" и "белое".
Речь не идёт о «чёрном» или «белом». Речь идёт о «чёрном с проблесками белого» и «о белом с пятнышками чёрного».
G>В некоторых случаях непрохождение некоторых проверок не является критичным (например надо релизнуть в срок). Тем не менее надо постоянно стремиться чтобы все проверки проходились.
Q>Так ведь если задача занимает 8 часов, я обязательно захочу закоммитить промежуточные результаты раз пять, пока её сделаю. Создать точки отката перед рисковыми рефакторингами, etc.
Вопрос конечно интересный. С одной стороны, ваша правда — версионность именно для этого и нужна, а сдругой — создавать ветку каждый день — это как-то странно. А реже — хуже в плане слияния. Ветка разработки чисто психологически хочет жить дольше, хотя должна именно как можно короче.
В общем я привык использовать SVN без философии: нужна ветка — делаем, пока не нужна — коммит напрямую в транк.
Здравствуйте, VGn, Вы писали:
VGn>Вопрос конечно интересный. С одной стороны, ваша правда — версионность именно для этого и нужна, а сдругой — создавать ветку каждый день — это как-то странно. VGn>В общем я привык использовать SVN без философии: нужна ветка — делаем, пока не нужна — коммит напрямую в транк.
Да нет, у нас тоже нет безусловного правила создания ветвей на каждый чих. Как раз CI-сервер амортизирует риски прямых коммитов в транк. Если я вижу последовательность шагов выполнения задачи такую, что позволит часто коммититься, не ломая транк, то я предпочту не плодить сущностей сверх необходимости. Но не всегда такую последовательность можно спрогнозировать, более надёжный способ всё-таки бранч.
VGn>Ветка разработки чисто психологически хочет жить дольше, хотя должна именно как можно короче.
Здравствуйте, avpavlov, Вы писали:
B>>* главная ветка B>>** ветка проекта
A>Не пойму, что такое "ветка проекта"? В чём отличие от главной? Главная — это транк? А ветка проекта — это новая версия?
Типа этого, т.е. главная ветка — это транк.
Когда начинается новый проект, отращивается новая ветка и все делается только там.
Здравствуйте, avpavlov, Вы писали:
B>>Типа этого, т.е. главная ветка — это транк. B>>Когда начинается новый проект, отращивается новая ветка и все делается только там.
A>Ни хрена не понял. Новый проект — это отдельное самостоятельное приложение? Или мы слово "проект" с тобой по разному понимаем?
Не совсем понятно, что тебе не понятно...
Новый проект — это это новый проект
Целью проекта обычно является выпуск новой версии софта.
Так вот, когда начинается новый проект, то много чего делается.
В том числе отращивается новая ветка в системе котроля версий.
Одновременно могут быть активными несколько проектов.
B>Типа этого, т.е. главная ветка — это транк. B>Когда начинается новый проект, отращивается новая ветка и все делается только там.
А транк замораживается что ли? Имхо такой вариант немного не по сути SVN, хотя собственно влияет только на название веток.
----
В курсе, что лаврушка и чайный куст — это деревья, лещина/орешник/фундук — это куст, арахис — это бобы, а ананас вообще овощ?
Здравствуйте, VGn, Вы писали:
B>>Типа этого, т.е. главная ветка — это транк. B>>Когда начинается новый проект, отращивается новая ветка и все делается только там.
VGn>А транк замораживается что ли? Имхо такой вариант немного не по сути SVN, хотя собственно влияет только на название веток.
Ну я осознанно не использовал термин "транк", потому что у нас не SVN.
Но суть от этого не меняется.
Подобный подход можно применять с любой системой,
где нормально поддерживаются ветки.
А транк не замораживается.
Это незачем делать, потому что там все равно ничего не происходит.
Только когда проект закончен, то состояние проекта сливается в транк.
Т.е. в транке реально только стабильные версии, естественно помеченные "релизным тагом".
VGn>---- VGn>В курсе, что лаврушка и чайный куст — это деревья, лещина/орешник/фундук — это куст, арахис — это бобы, а ананас вообще овощ?
B>Ну я осознанно не использовал термин "транк", потому что у нас не SVN. B>Но суть от этого не меняется. B>Подобный подход можно применять с любой системой, B>где нормально поддерживаются ветки.
B>А транк не замораживается. B>Это незачем делать, потому что там все равно ничего не происходит. B>Только когда проект закончен, то состояние проекта сливается в транк. B>Т.е. в транке реально только стабильные версии, естественно помеченные "релизным тагом".
Просто транк, он потому и прозван основной веткой (или стволом), потому что в ней и происходят обычно все движения, а релизы наоборот ответвляют в отдельные ветки, которые потом порастают мхом.
Описанный вариант событий, я так понимаю, политикой коротких коммитов назвать трудно. А значит слияние у вас тот ещё секс.
Здравствуйте, VGn, Вы писали:
VGn>Описанный вариант событий, я так понимаю, политикой коротких коммитов назвать трудно.
С чего ты так решил?
В своей ветке могу коммитить хоть каждую минуту.
VGn>А значит слияние у вас тот ещё секс.
Хм... ну я же даже в исходном сообщении написал, что оверхед минимален.
Все конфликты решаются на том уровне, где они возникают.
Т.е. если я как девелопер, намудрил, то проблемы проявятся только в моей ветке
и я вынужден буду их разрешить до того, как я что-то солью со своей ветки
в ветку группы фич.
Конечно, чем меньше координации на проекте, тем больше проблем будет с мерджами.
Если я добавил в интерфейс новый метод, а мой коллега решил,
что интерфейс вообще нафиг не нужен, то проблемы с мерджами гарантированы.
Но тут тебя никакой тул не спасет.
Наш подход только гарантирует, что проблемы, если они возникают,
локализируются очень быстро, они всегда локальны и практически никогда не затрагивают всю команду.
Ну а слияние в транк — это у нас всегда скучнейшая процедура, при которой не возникают никаких проблем.
Здравствуйте, Roman Odaisky, Вы писали:
RO>И напоследок о тех, кто не использует РСКВ:
Спасибо за ссылку, любопытно. Причем комменты тоже местами полезны.
Однако, РСКВ в данном случае бы тоже не помогли. Судя по описанию (других источников нет, поэтому получается сугубо ИМХО), проблема в бюрократии и имитации деятельности, а не в иерархии репозиториев. Довелось мне быть участником команды, писавшей код для моторолы. Так вот там, при всей куче народу, делавшего систему большой сложности (для тогдашних телефонов писалась и поддерживалась своя операционка), при всех сложных и порой циклических зависимостя, всё было значительно лучше, чем в приведенном описании. И там использовалась централизованная модель разработки с использованием IBM Rational ClearCase. Разделение на репозитории было минимальным и не иерархическим, а "параллельным", т.е. была репликация центрального репозитрия. И вот в таких жестко центализованных улосиях продукты разарабатывались и выпускались вполне в рамках дэдлайнов.
В общем, как обычно, проблема в статье — не из-за тулов, а из-за организации труда.
Здравствуйте, Aquary, Вы писали:
A>Однако, РСКВ в данном случае бы тоже не помогли. <...> использовалась централизованная модель разработки с использованием IBM Rational ClearCase. Разделение на репозитории было минимальным и не иерархическим, а "параллельным", т.е. была репликация центрального репозитрия.
Чем не имитация распределенных СКВ средствами централизованных?
A>В общем, как обычно, проблема в статье — не из-за тулов, а из-за организации труда.
Оно-то так, но некоторые средства помогают организовать труд и ненавязчиво направляют его в нужную сторону. Если в средствах тяжело merge-ить, то это будут делать редко. Если коммиты тяжеловесны, то же самое. Если нет rebase и история засоряется ненужными слияниями, то ей будут реже пользоваться. Если баги заводить тяжело, то этого будут избегать. И т. д.
Кстати, в Линуксе изменения тоже отнюдь не сразу попадают в mainline, но это никого не волнует, потому что любой может взять себе изменения из любой ветки и потом это будет учтено при слиянии. (Хотя сравнение и не совсем корректно, Линукс ведь только ядро, а в статье наверняка имелась в виду вся ОС, с GUI и прочим.)
Здравствуйте, Roman Odaisky, Вы писали:
RO>Чем не имитация распределенных СКВ средствами централизованных?
Тем, что описанный механизм Multisite не отменяет централизации разработчиков вокруг своей копии базы на сайте (т.е. местоположении команды). И к этой копии они обращаются централизованно. Кроме того, существует жесткая система авторизации для каждого сайта, и пользователь с одного сайта далеко не всего может обратиться к другой базе — для этого ему дать соответствующие права. Сам Multisite не является обязательным к использованию. Без него каждый отдельный сайт работает как централизованное целое. В распределенных же системах каждый делает что хочет и при необходимости обращается к любому из репозиториев.
A>>В общем, как обычно, проблема в статье — не из-за тулов, а из-за организации труда.
RO>Оно-то так, но некоторые средства помогают организовать труд и ненавязчиво направляют его в нужную сторону. Если в средствах тяжело merge-ить, то это будут делать редко. Если коммиты тяжеловесны, то же самое. Если нет rebase и история засоряется ненужными слияниями, то ей будут реже пользоваться. Если баги заводить тяжело, то этого будут избегать. И т. д.
Согласен — человек должен работать не вопреки, а благодаря тузлам. Однако большинство сегодняшних систем контроля достаточно зрелы, чтоб рассматривать не их недостатки, а модели разработки на их основе.
RO>Кстати, в Линуксе изменения тоже отнюдь не сразу попадают в mainline, но это никого не волнует, потому что любой может взять себе изменения из любой ветки и потом это будет учтено при слиянии. (Хотя сравнение и не совсем корректно, Линукс ведь только ядро, а в статье наверняка имелась в виду вся ОС, с GUI и прочим.)
Собственно, сложно ожидать от такой огромной системы отсутствия промежуточных стадий сборки и проверки. Разумеется, код должен предварительно отстаиваться, ревьюиться — и делается это явно не на mainline.
В описанном подходе Майкрософта есть своё рациональное зерно, задумано всё очень интересно. Однако — неповоротливость самой компании всё губит. Думаю, у них и любая DVCS так же пролегла бы пропастью между командами, ставя лишние преграды для взаимодействия.
В общем, подход МС и подход команды ядра линукса суть две противоположности организации контроля версий. Однако проистекают они из принципиальной разницы самой модели разработки, отсюда и такая разница в средствах.
Здравствуйте, Aquary, Вы писали:
RO>>Чем не имитация распределенных СКВ средствами централизованных?
A>Тем, что описанный механизм Multisite не отменяет централизации разработчиков вокруг своей копии базы на сайте (т.е. местоположении команды). И к этой копии они обращаются централизованно. Кроме того, существует жесткая система авторизации для каждого сайта, и пользователь с одного сайта далеко не всего может обратиться к другой базе — для этого ему дать соответствующие права. Сам Multisite не является обязательным к использованию. Без него каждый отдельный сайт работает как централизованное целое. В распределенных же системах каждый делает что хочет и при необходимости обращается к любому из репозиториев.
РСКВ часто так и работают, см. ниже.
A>Собственно, сложно ожидать от такой огромной системы отсутствия промежуточных стадий сборки и проверки. Разумеется, код должен предварительно отстаиваться, ревьюиться — и делается это явно не на mainline.
A>В описанном подходе Майкрософта есть своё рациональное зерно, задумано всё очень интересно. Однако — неповоротливость самой компании всё губит. Думаю, у них и любая DVCS так же пролегла бы пропастью между командами, ставя лишние преграды для взаимодействия.
РСКВ с легкостью позволяют организовать многоуровневую иерархическую структуру, при которой maintainer’ы собирают изменения своих «подчиненных» и передают их выше. При этом инфраструктура тестирования, code review и т. п. может быть в нескольких местах. В то же время описанная майкрософтовская иерархия выглядит попыткой натянуть одну ЦСКВ на огромную команду, для чего их средства не предназначены.
A>В общем, подход МС и подход команды ядра линукса суть две противоположности организации контроля версий. Однако проистекают они из принципиальной разницы самой модели разработки, отсюда и такая разница в средствах.
Не соглашусь. В чём разница-то? В Линуксе команды независимы и удалены одна от другой, но и в Windows тоже. В Линуксе изменения плавно всплывают наверх, откуда их все потом берут, в Windows тоже. В Линуксе есть своя собственная СКВ, в Windows тоже — только git распределенный, а TFS нет.
Здравствуйте, Roman Odaisky, Вы писали:
A>>Тем, что описанный механизм Multisite не отменяет централизации разработчиков вокруг своей копии базы на сайте (т.е. местоположении команды). И к этой копии они обращаются централизованно. Кроме того, существует жесткая система авторизации для каждого сайта, и пользователь с одного сайта далеко не всего может обратиться к другой базе — для этого ему дать соответствующие права. Сам Multisite не является обязательным к использованию. Без него каждый отдельный сайт работает как централизованное целое. В распределенных же системах каждый делает что хочет и при необходимости обращается к любому из репозиториев.
RO>РСКВ часто так и работают, см. ниже.
Не соглашусь. Идея DVCS — отход от централизованной работы, приоритет — обмену дельтой между произвольными нодами, а центральные репозитории служат лишь для создания baselines. CVCS настаивают на том, что произвольных нод быть не должно, а реплики репозитория — лишь способ масштабировать базу.
RO> В то же время описанная майкрософтовская иерархия выглядит попыткой натянуть одну ЦСКВ на огромную команду, для чего их средства не предназначены.
Я бы сказал: иерархия — следствие метода организации работы в целом, а натягивание централизованной системы на эту структуру — лишь следствие. И если заменить CVCS на DVCS — ничего бы не поменялось, т.к. организация работы команд в целом осталась бы той же.
RO>Не соглашусь. В чём разница-то? В Линуксе команды независимы и удалены одна от другой, но и в Windows тоже. В Линуксе изменения плавно всплывают наверх, откуда их все потом берут, в Windows тоже. В Линуксе есть своя собственная СКВ, в Windows тоже — только git распределенный, а TFS нет.
Описанный случай относится к 2006 году, тогда (а возможно и сейчас) использовали систему контроля SourceDepot, основанную на Perforce.
Насчет удаленных команд — отчасти это так. Однако если в Линуксе распределенность изначально была фактом, то в МС это лишь одно из обстоятельств, появивщихся со временем. В целом же система работы построена на централизацию и тесное взаимодействие; циклические зависимости, упомянутые в комментах, — как раз следствие такого централизованного подхода. Для Линукса их в принципе нет, т.к. разработчики ядра изначально наверняка понимали, что не смогут ими эффективно управлять (по крайней мере, в первые годы работы).
)
Ну и более ответственно подходить к моменту отведения бранча.
