Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Mr.Cat, Вы писали:
Q>>>Под частой синхронизацией подразумевается частое чтение из транка, а не частое его изменение. MC>>Вполне очевидно, что читать транк чаще, чем он меняется, невозможно. Поэтому высокая частота вливания из транка в бранчи подразумевает высокую частоту обратного процесса. В итоге, на мой взгляд, суперстабильный транк подходит для обмена изменениями только между супернезависимыми командами разработчиков.
Q>Никто не отменял бранчи для обмена изменениями. У них могут быть более мягкие условия по отношению к стабильности.
Q>Бранчи — они ж не только для изоляции, они ж ещё для коллаборации
Вернее так: их можно использовать для коллаборации, но это очень неудобно.
Здравствуйте, gandjustas, Вы писали:
G>>>Если нужен Save без publish, то вполне можно использовать такую фичу. В TFS она называется shelve, в SVN подобной нету, про другие СКВ не знаю. MC>>В svn можно создать ветку и текущие изменения закоммитить туда. G>Только появляется геморрой со свитчем веток, их именованием и тому подобным. Это уже не работает как кнопка Save.
git stash
Здравствуйте, 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, которые фактически отличаются тем насколько часто надо создавать ветки. Большое количество веток ведет к оверхеду по слиянию веток, но делает разработку фич отдельными командами или людьми более независимой.
Общая формула — частота создания веток обратно пропорциональна уровню централизованности разарботки.
Здравствуйте, gandjustas, Вы писали:
G>В других системах есть другие возвожности сохраненения изменений, кроме веток, рассчитанные на определенные сценарии работы. Они определенно удобнее веток будут для этих сценариев.
Например? Shelves? Они не для коллаборации (АКА взаимодействия). Они для временного сохранения изменений без образования бранча, для демонстрации своих результатов без образования бранча. По сути это — кастрированный бранч.
Какие ещё способы взаимодействия через VCS, но без бранчей ты знаешь?
A>>Вводная информация: проект с 30-40 разработчиками в одной команде (одна компания) и с сотней разработчиков в общей команде, разбросанной по всему миру (большая корпорация с несколькими контракторами). G>Смотря какая СКВ и какой проект.
Приведи свой пример — ты сказал, что есть способы безболезненного взаимодействия через VCS, но без бранчей. Назови свой пример подобного взаимодействия с указанными условиями.
G>Существует несколько branching strategies, которые фактически отличаются тем насколько часто надо создавать ветки.
Ты сказал branching strategies. Т.е. ветвление таки должно быть?
G>Большое количество веток ведет к оверхеду по слиянию веток, но делает разработку фич отдельными командами или людьми более независимой.
В чем заключается оверхед? В том, что надо мержить с веток на главную линейку? Ты хоть какие shelves используй — без слияния девелоперских изменений не обойдешься.
G>Общая формула — частота создания веток обратно пропорциональна уровню централизованности разарботки.
Неверно. Чем больше централизована разработка, тем больше необходимость ветвления для отдельного разработчика. Представь единый центральный trunk (ситуация центральнее некуда), десяток разработчиков. Ты им предлагаешь жить без веток? Допустим. Типа договариваются между собой насчет регулярных мержей и т.п. (глюк, но допустим.) Появляется ещё десяток разработчиков ... Твои действия? Разумеется, ты их всех хором отправляешь на отдельные ветки или shelve'ы (смотря что больше принято в твоей VCS). Получатся — централизованная разработка — много веток.
Повторю — кажущийся оверхед по мержам — ничто по сравнению с бардаком, который получаешь при отсутствии веток.
Здравствуйте, 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 веток для нового релиза. Только все разработчики не видели изменения друг друга и тут начинается веселье...
Для этого в крупных командах выделяется роль (а иногда и должность) интегратора. Девелоперы дают ему свои ветки (просто указывая ветки или ревизии), и продолжают заниматься тем, что становится более приоритетным. Интегратор же один за одним сращивает изменения (как правило, это происходит автоматом, конфликты составляют небольшой процент), прогоняет автотесты, отдает на руное тестирование и т.п. и далее самостоятельно интегрирует изменения на транк.
Конечно, выделенная роль интегратора подходит только средним и крупным командам. днако мы ведь про них речь и ведем?
Здравствуйте, 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, Вы писали:
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>Если делать коммиты в транк, и, не дай бог, кто-то начнёт использовать неустойчивые результаты — то объём действий при слиянии существенно увеличится.
Вывод — при разработке в транке не надо часто синхронизировать с ним бранчи. Проще отвести новый бранч и немного допилить до стабильного состояния Ну и более ответственно подходить к моменту отведения бранча.
ЗЫ. Ещё раз — я не говорю, что что-то хорошо, а другое плохо. Всё зависит от контекста.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, frogkiller, Вы писали:
F>>>Только почему нельзя закоммитить рабочую копию? Q>>Потому что SVN-сервер не пропустит! Он потребует сделать предварительный апдейт. И при этом придётся сделать merge и resolve conflicts. И всё это — «наживую», в «красной» рабочей папке, малейшая ошибка чревата безвозвратной потерей локальных изменений. F>И?
Не буду в шестой раз повторять, почему манипуляции с сохранёнными данными (в нашем случае, с сохранённой историей ревизий) лучше, чем с несохранёнными.
F>Закоммитить не проблема
Закоммитить не проблема, предварительно проапдейтить проблема.
F>возможной проблемой (для твоего подхода) будет то, что закоммиченное может даже и не собираться, не говоря уже о тестах.
Для твоего подхода. Это ведь ты предлагаешь «раннее использование» недоделанного кода?
F>Это зависит от дисциплины и от разных вспомогательных средств.
Называется это вспомогательно средство «сервер непрерывной интеграции», он и проверяет транк на поломанность. Только использовать его предполагается в режиме «поломал — починил», а не «не доделал — не доделал — почти доделал — допилил». В некоторых CI-серверах есть такой счётчик пользователя как карма. Не проверил билд перед коммитом, сломал транк — получи минус в карму :)
F>Например, можно слать письма-напоминалки сломавшему сборку/тест.
Да хоть твиттер-сообщения.
F>Да, транк становится нестабильным — ну и что с того. Заказчику и тестерам можно показывать специальные стабильные бранчи, которые потом и релизить.
Где ж их взять-то, стабильные бранчи? Как поймать момент стабильности транка, чтоб ответвить от него стабильный бранч?
Я так понимаю, ты шаг за шагом всё таки склоняешься к необходимости бранчевания.
F>А теперь представь, что это не два разработчика, а две команды, человек по 30 в каждой, они делают по сотне коммитов в день, а кроме них есть ещё несколько команд, которые тоже не сидят сложа руки. Тут будет сразу несколько таких обменных бранчей, и они разъедутся очень-очень быстро.
А теперь представь, что они одновременно коммитят неконсистентные, промежуточные шаги в транк.
Бранчевание, поддержка непротиворечивости и чистоты стабильных веток — это общепринятая практика. Никто так просто не позволит коммитить в стабильные ветки ядра Линукса. Но это не повод не коммитить вообще.
F>Вывод — при разработке в транке не надо часто синхронизировать с ним бранчи.
Нужно всё как можно чаще (коль скоро это не нарушает других ограничений) синхронизировать. Merge early, merge often.
F>Проще отвести новый бранч и немного допилить до стабильного состояния ;)
Здравствуйте, Qbit86, Вы писали:
F>>Да, транк становится нестабильным — ну и что с того. Заказчику и тестерам можно показывать специальные стабильные бранчи, которые потом и релизить. Q>Где ж их взять-то, стабильные бранчи? Как поймать момент стабильности транка, чтоб ответвить от него стабильный бранч?
А не обязательно ловить "момент стабильности". Можно какое-то время стабилизировать отведённый бранч — так чтобы проходили желаемые тесты.
Q>Я так понимаю, ты шаг за шагом всё таки склоняешься к необходимости бранчевания.
Не совсем. Какая-то стабильность несомненно нужна, и отдельные feature-бранчи необходимы. Мне только не нравится чрезмерная жётскость в транке.
F>>А теперь представь, что это не два разработчика, а две команды, человек по 30 в каждой, они делают по сотне коммитов в день, а кроме них есть ещё несколько команд, которые тоже не сидят сложа руки. Тут будет сразу несколько таких обменных бранчей, и они разъедутся очень-очень быстро.
Q>А теперь представь, что они одновременно коммитят неконсистентные, промежуточные шаги в транк. Q>Бранчевание, поддержка непротиворечивости и чистоты стабильных веток — это общепринятая практика. Никто так просто не позволит коммитить в стабильные ветки ядра Линукса. Но это не повод не коммитить вообще.
Стабильные ветки — это не транк. Это как раз то, что я пытаюсь тебе описать. Что тебе не нравится в модели: отвели бранч — какое-то время его стабилизировали — релиз — готовят новый бранч? Причём не обязательно эти стадии должны идти строго последовательно (можно отвести следующий бранч во время стабилизации предыдущего). При этом транк иногда может находиться в нерабочем состоянии.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, frogkiller, Вы писали:
F>Что тебе не нравится в модели: отвели бранч — какое-то время его стабилизировали — релиз — готовят новый бранч?
Мне ненравится следующее: F>При этом транк иногда может находиться в нерабочем состоянии.
Точнее — «почти всегда».
Мне хочется быть уверенным, что приходящие changeset'ы качественны. Не идеальны и безошибочны, а минимально корректны в терминах, обозначенных выше: код собирается (т.е. найдены все пререквизиты для сборки, не осталось незакоммиченных файлов), проходят тесты, проходят инспекцию бинарного и исходного кода (нет опечаток в идентификаторах, не забыли подписать сборки), в проектах правильно прописаны имена выходных dll-ек (Контора.Проект.*.dll), etc.
Я хочу быть уверенным, что если после апдейта возникнут проблемы с этой базовой валидацией, то это мои проблемы (которые я могу исправить), а не чужие недоделки (которые я исправить не могу, и вынужден ждать, пока автор доделает).
Я хочу, чтобы эту минимальную корректность проверяла автоматика, а не «Эй, Вась, а ты не забыл закоммитить файл MyNewClass.cs?» Etc, etc, etc.
Ну и более ответственно подходить к моменту отведения бранча.