На вики описана довольно поучительная история.
«Активная деятельность братьев по юридической защите своих прав препятствовала их работе по созданию новых моделей самолётов, и в результате к 1911 году самолёты Райт считались худшими по сравнению с другими, произведёнными в Европе. В результате развитие авиации США было замедлено до такой степени, что при вступлении США в Первую мировую войну армия страны из-за отсутствия современной американской модели была вынуждена закупать французские машины.»
Вы невнимательно прочитали концепцию. Против всех ваших аргументов в технологии есть подпорки.
1 — наверное это из-за того, что модуль имеет очень много связей со внешней средой. Поэтому я и предлагаю первым делом прятать модуль под интерфейсом, чтобы переключение было возможно.
2 — смотреть глазами и думать головой в моём случае тоже надо. 80-90% кода покрывается просто. Оставшиеся 10% добить очень сложно, это обычно обработка ошибок. Отлично, если вы их покроете. Но реальность такова, что 100% -ого покрытия не бывает. :( Ещё раз повторюсь — в моём случае «старая ветка» сохраняется и переключается локально одной настройкой в конфиге.
3 — а у меня проект занимает 34 ГБ. :) Новая ветка делается быстро, но чекаутится долго. Про SVN и меркуриал я уже писал в комментах.
4 — Ещё раз повторюсь. Отрефактореный код просто лежит в репо и не включается до тех пор, пока не оттестирован на всех платформах и т.п. На случай фейла всегда есть флажок в конфиге.
>>Любые отдельные ветки — зло
Слишком категорично. Ветки рулят, если надо делать стабильный релиз не останавливая работу в транке. Или надо суппортить несколько версий одного проекта одновременно.
ИМХО ветки могут жить если мерди идут только в одну сторону — из транка в ветку.
Геймдизайнеры, художники, и все остальные. 200+ человек. Как им не давать svn? Как они работать тогда будут? Они производят 70% всех коммитов.
Изначально у нас был SVN. SVN прост и понятен всем. Ветки, rebase, патчи и т.п. это сложно и мало кому нужно. Народ будет путаться и чаще косячить. Осилить наверное смогут, но нафига? Этож надо переучить уйму народа, перенастроить софт, переписать коммит хуки (у нас их сотни)… Слишком много гемора.
Кроме того mercurial плохо справляется, если в него закачать весь наш проект, поэтому у нас в нём только код.
Дело в том, что если делается рефакторинг, то код очень живой и часто меняется. Поэтому действительно каждый раз мерджить надо как по новому. Ну в любом случае, если не было коммита, то не решается проблема «автоматического рефакторинга отрефактореного кода».
Насколько я понимаю, гит это примерно тоже самое что и mercurial.
У нас общий SVN + у программеров локальный mercurial с гейтом в SVN. У нас тоже есть rebase. Но rebase каждый день, это мердж каждый день. Пробовал и так. Выдержал неделю :) Слишком тяжело каждый день начинать с часового мерджа. С Mercurial это делать легче чем с SVN, но всё равно не намного.
Mercurial, кстати, позволяет играться с локальными ветками и патчами, перекладывая их туда-сюда. Но не решает глобальной проблемы «Ваш код живёт в отдельной ветке, а значит он не рефакторится другими программистами».
1 — в моём варианте всё тоже самое, только ещё проще. поменял настройку в конфиге и транк работает.
2 — не понял аргумента :( Как сравнивать с другой версией, если классы переколбашены на 70-100%? Всё равно смотреть только глазами, а не диффом.
3 — наш проект чекаутится 2 часа.
4 — в моём случае сломать билд можно только сломал в компиляцию. И то, если сам дурак и не проверил её до коммита. Ничего страшного, быстрый фикс или реверт всё всегда чинит. От билда зависят 100+ человек, это да. Всё равно его будут ломать, и не важно как. Мой код ничем не отличается от любого другого кода. Практика показывает, что компиляция ломается примерно раз в два дня и чинится в течение 15 минут. При ответственном отношении и быстром фиксе это не проблема.
Конечно, мерджа я же не избегаю, просто я делаю его вручную. Автоматика всё равно не справляется. И мой код в отдельной папочке это по сути и есть ветка, только не отдельной части репо, а прямо в коде.
Чтоб было понятно, если мне не изменяет память, то описанную мной схему мы применяли как минимум раз 6. Плюси и минусы схемы изучены, и в технологии расставлены подпорки, чтобы уменьшить влияние минусов.
Пробовал ветки, не прокатило. По двум основным причинам и несколльким дополнительным.
— В случае больших рефакторингов мердж бывает настолько сложен, что проще застрелиться. 100% изменений приходится переносить вручную построчно. Т.е. по большому счёту нет разницы между веткой и кодом лежащим в соседней папке.
— Ваш код живёт в отдельной ветке, а значит от не рефакторится другими программистами. В моём случае, переименование метода в какой-то внешней подсистеме, которую использует наша подсистема, будет подсуппорчено автоматически, средствами IDE. В случае с веткой, такой рефакторинг надо будет делать вручную. Если над проектом работает 10+ программистов, кто-то что-то да переименует раз в 3 дня стабильно.
— Чтоб гонять тесты на одной и второй системе не надо переключаться между ветками
— Коллегам проще показывать что-то в существующем коде а не просить вычекать новую ветку.
Справедливости ради… У ветки есть одно, но сомнительное преимущество — своим рефакторингом не сломаешь билд транка.
10 лет занимаюсь БД и не знаю ответа на этот вопрос.
— «какой механизм и как производит проверку безопасности запуска транзакции»
10 лет занимаюсь БД и даже не понял о чём вопрос.
На остальные вопросы я бы мог ответить, но не прошёл бы второй этап… видимо я лох :)
Во все нормальные IDE сейчас встраивают статический анализ кода, так что вопрос анализировать или не анализировать статически уже вобщем-то не стоит.
На вики описана довольно поучительная история.
«Активная деятельность братьев по юридической защите своих прав препятствовала их работе по созданию новых моделей самолётов, и в результате к 1911 году самолёты Райт считались худшими по сравнению с другими, произведёнными в Европе. В результате развитие авиации США было замедлено до такой степени, что при вступлении США в Первую мировую войну армия страны из-за отсутствия современной американской модели была вынуждена закупать французские машины.»
Страх он от отсутсвия тестов. Много тестов — have no fear!
1 — наверное это из-за того, что модуль имеет очень много связей со внешней средой. Поэтому я и предлагаю первым делом прятать модуль под интерфейсом, чтобы переключение было возможно.
2 — смотреть глазами и думать головой в моём случае тоже надо. 80-90% кода покрывается просто. Оставшиеся 10% добить очень сложно, это обычно обработка ошибок. Отлично, если вы их покроете. Но реальность такова, что 100% -ого покрытия не бывает. :( Ещё раз повторюсь — в моём случае «старая ветка» сохраняется и переключается локально одной настройкой в конфиге.
3 — а у меня проект занимает 34 ГБ. :) Новая ветка делается быстро, но чекаутится долго. Про SVN и меркуриал я уже писал в комментах.
4 — Ещё раз повторюсь. Отрефактореный код просто лежит в репо и не включается до тех пор, пока не оттестирован на всех платформах и т.п. На случай фейла всегда есть флажок в конфиге.
Слишком категорично. Ветки рулят, если надо делать стабильный релиз не останавливая работу в транке. Или надо суппортить несколько версий одного проекта одновременно.
ИМХО ветки могут жить если мерди идут только в одну сторону — из транка в ветку.
Изначально у нас был SVN. SVN прост и понятен всем. Ветки, rebase, патчи и т.п. это сложно и мало кому нужно. Народ будет путаться и чаще косячить. Осилить наверное смогут, но нафига? Этож надо переучить уйму народа, перенастроить софт, переписать коммит хуки (у нас их сотни)… Слишком много гемора.
Кроме того mercurial плохо справляется, если в него закачать весь наш проект, поэтому у нас в нём только код.
У нас общий SVN + у программеров локальный mercurial с гейтом в SVN. У нас тоже есть rebase. Но rebase каждый день, это мердж каждый день. Пробовал и так. Выдержал неделю :) Слишком тяжело каждый день начинать с часового мерджа. С Mercurial это делать легче чем с SVN, но всё равно не намного.
Mercurial, кстати, позволяет играться с локальными ветками и патчами, перекладывая их туда-сюда. Но не решает глобальной проблемы «Ваш код живёт в отдельной ветке, а значит он не рефакторится другими программистами».
2 — не понял аргумента :( Как сравнивать с другой версией, если классы переколбашены на 70-100%? Всё равно смотреть только глазами, а не диффом.
3 — наш проект чекаутится 2 часа.
4 — в моём случае сломать билд можно только сломал в компиляцию. И то, если сам дурак и не проверил её до коммита. Ничего страшного, быстрый фикс или реверт всё всегда чинит. От билда зависят 100+ человек, это да. Всё равно его будут ломать, и не важно как. Мой код ничем не отличается от любого другого кода. Практика показывает, что компиляция ломается примерно раз в два дня и чинится в течение 15 минут. При ответственном отношении и быстром фиксе это не проблема.
Конечно, мерджа я же не избегаю, просто я делаю его вручную. Автоматика всё равно не справляется. И мой код в отдельной папочке это по сути и есть ветка, только не отдельной части репо, а прямо в коде.
Чтоб было понятно, если мне не изменяет память, то описанную мной схему мы применяли как минимум раз 6. Плюси и минусы схемы изучены, и в технологии расставлены подпорки, чтобы уменьшить влияние минусов.
— В случае больших рефакторингов мердж бывает настолько сложен, что проще застрелиться. 100% изменений приходится переносить вручную построчно. Т.е. по большому счёту нет разницы между веткой и кодом лежащим в соседней папке.
— Ваш код живёт в отдельной ветке, а значит от не рефакторится другими программистами. В моём случае, переименование метода в какой-то внешней подсистеме, которую использует наша подсистема, будет подсуппорчено автоматически, средствами IDE. В случае с веткой, такой рефакторинг надо будет делать вручную. Если над проектом работает 10+ программистов, кто-то что-то да переименует раз в 3 дня стабильно.
— Чтоб гонять тесты на одной и второй системе не надо переключаться между ветками
— Коллегам проще показывать что-то в существующем коде а не просить вычекать новую ветку.
Справедливости ради… У ветки есть одно, но сомнительное преимущество — своим рефакторингом не сломаешь билд транка.
*парадигмы
*получилась