Ветки в SVN

    Особенностью современной веб разработки является полное отсутствие планирования при создании, поддержке и выкатке проектов. Это приводит к ситуации, что достаточно часто параллельно выполняется несколько разных задач и сроки их выкатки в production никак не соотносятся. А значит традиционный подход с созданием релизов не годится.

    На помощь нам приходит механизм создания веток в системах контроля версий, VCS (в нашем случае это Subversion). Ветки это разные варианты одного документа или проекта, с общей историей изменений до точки ветвления и с разными — после неё.

    Создание



    Ветка создается очень просто:

    svn copy svn://svnserver.ru/КЛИЕНТ/ПРОЕКТ/trunk svn://svnserver.ru/КЛИЕНТ/ПРОЕКТ/branches/НАЗВАНИЕ_ВЕТКИ -m 'КАКОЙ ТО КОММЕНТАРИЙ О ВЕТКЕ'


    Теперь, чтобы изменения разработчика сохранялись не в основном стволе разработки (trunk), а в выбранной ветке, он должен переключится на эту ветку.

    cd ~/web/КЛИЕНТ/ПРОЕКТ # переходим в основную папку проекта
    svn sw svn://svnserver.ru/КЛИЕНТ/ПРОЕКТ/branches/НАЗВАНИЕ_ВЕТКИ
    svn update # нужно в тех случаях, когда в проекте используются svn:externals с относительными ссылками


    Теперь можно вести разработку в ветке, не беспокоясь, что не утвержденные или не проверенные решения попадут в production. При этом разработчик работает со своим хостом ЛОГИН_РАЗРАБОТЧИКА.ПРОЕКТ.КЛИЕНТ.devserver.ru

    Чтобы показать готовое или промежуточное решение создается тестовый хост для этой ветки. Нужно автоматизировать этот процесс, чтобы разработчики не тратили на это время. Менеджеры и тестировщики всегда проверяют решение только на тестовом хосте НАЗВАНИЕ_ВЕТКИ.ПРОЕКТ.КЛИЕНТ.devserver.ru. Проверять что либо на хосте разработчика нельзя. Потому что:
    • разработчики норовят забыть что-то закоммитить. Из за этого другой разработчик, работающий с той же задачей или выкатывающий решение может долго не понимать, где собственно все.
    • иногда разработчики оставляют в коде привязки к своему хосту. Изза этого решение работает только у них, а при выкатке все ломается.
    • многие, особенно разработчики со стажем, новорят внести какие то исправления «вслепую» и не проверяя их коммитить. Это приводит к падению сервиса на production и серии коммитов-хотфиксов с комментарием «Ой, бля»


    Поэтому единственно правильной практикой будет:
    1. выполнить задачу
    2. закоммитить изменения
    3. выкатить их на тестовый сервер
    4. самому глазами хотя бы один раз посмотреть, что все выкатилось там корректно
    5. опубликовать ссылку на проблемное место на тестовом хосте в задаче (в мегаплане или другом тасктрекере)


    Последнее надо делать, даже если в задаче эта ссылка несколько раз встречалась. Потому что из за спешки или невнимательности 4 действия из описанных 5 могут быть пропущены.

    Слияние


    После того как менедежер проверил решение и не нашел ошибок нужно вливать ветку в trunk.

    Допустим у нас есть ветка A (trunk), в которой ведется основная разработка. В ревизии 100 мы отпочковываем от нее ветку B (branches/НАЗВАНИЕ_ВЕТКИ) (A@100, B@101) Затем обе ветки активно развиваются продолжительное время (A@167, B@189) и нам надо их слить. Если сливать «в лоб» (sw A, merge A B) то будет очень много конфликтов, которые очень сложно разрешить Правильный подход следующий:

    svn switch svn://svnserver.ru/КЛИЕНТ/ПРОЕКТ/branches/НАЗВАНИЕ_ВЕТКИ  # переключаемся в B
    svn merge -r 101:167 svn://svnserver.ru/КЛИЕНТ/ПРОЕКТ/trunk .        # вливаем туда все изменения произошедшие в A с момента отпочкования (или **последнего слияния**)
    svn ci -m 'merge with -r 101:167 trunk'                              # разрешаем возникшие конфликты (их должно быть меньше, чем в первом случае) и коммитим. В коммите указываем какие именно изменения мы забрали
    svn switch svn://svnserver.ru/КЛИЕНТ/ПРОЕКТ/trunk                    # переключаемся в A
    svn merge svn://svnserver.ru/КЛИЕНТ/ПРОЕКТ/trunk svn://svnserver.ru/КЛИЕНТ/ПРОЕКТ/branches/НАЗВАНИЕ_ВЕТКИ .                       # вливаем туда изменения в B
    svn ci -m 'merge with НАЗВАНИЕ_ВЕТКИ@190'                            # конфликтов быть уже практически не должно, т.к. мы учли изменения A в предыдущем коммите


    Обращаю внимание: если ветки уже сливались в прошлом, то нужно брать в качестве начальной ревизии не ревизию отпочкования, а последнюю ревизию, в которой ветки были «одинаковыми». При чем это не обязательно может быть вливание изменений из A в B, могут быть и вливание B в A.

    В некоторых случаях конфликты все равно случаются, как правило если один и тот же участок кода изменялся в разных ветках. Есть инструкция по их разрешению. Нужно не забывать, что не обязательно ваше решение будет правильным в каждом конфликте, поэтому желательно чтобы merge делал человек, знакомый с изменениями в обоих сливаемых ветках и способный адекватно решить конфликт.

    После слияния нужно создать тестовый хост для trunk (trunk.ПРОЕКТ.КЛИЕНТ.devserver.ru) или обновить существующую папку. После этого кидаем в задачу ссылку на проблемное место на тестовом хосте в задаче. Зачем это делать, ведь мы только что проверили изменения на хосте ветки? Изменения, которые велись в trunk или другие изменения, которые были влиты в trunk могут повлиять на те правки, которые нам нужны. Чаще всего проблемы могут быть вызваны CSS, т.к. там просто общими правилами повлиять на очень много разделов, но бывают и другие ситуации. Поэтому еще одна проверка на trunk перед выкаткой очень нужна.

    Нерадивый менеджер


    Подчас менеджеру бывает совершенно наплевать на проект и более всего его беспокоит собственное душевное равновесие. Поэтому он с легкой душой пропускает шаги, которые кажутся ему не важными и пишет в задаче «Сделайте то-то и сразу же выкатывайте».

    И поэтому он уже в ближайшее время получит втык от клиента «Сейчас большинство абонентов на вебе не может … используя браузер IE. Мы в прошлый раз говорили, что больше половины пользователей им пользуются так что просьба тестировать все доработки в перую очередь на IE. Поправьте, пожалуйста, как можно быстрее данную ошибку!»

    Менеждер ставит задачу «СРОЧНО!!! ОШИБКА!!!» и забывает о проверках до следующего раза.

    Нарушение алгоритма «сделали → проверили → (исправили → проверили)*n → выкатили» приводит к появлению срочных задач-правок выбивающих разработчиков из ритма и отвлекающие от запланированных задач, портит нашу общую репутацию перед клиентами и пользователями и нифига не ускоряеет процесс.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 82

      +22
      Ветки в svn — это тихий ужас, лучше уж что-нибудь с нормальной нативной поддержкой веток иметь, а не эти костыли.
      Юзайте git лучше.
        +4
        Git/SVN это детали реализации
        речь в статье о другом
          0
          Лучше уж на примере того, где это нормально реализовано, показывать, вы бы еще на CVS попытались продемонстрировать принципы ветвления.
            +4
            Описанный рабочий процесс — интересный, но команды SVN для создания ветки и слияния выглядят просто жутко и отпугивают читателя. В GIT/Mercurial это просто 'git/hg merge', а все остальное система определяет автоматически.
            Очень советую, попробуйте Mercurial (он проще), тем более, что он работает с централизованными репозиториями SVN.
              +1
              Команды svn приведённые в статье не раскрывают всех возможностей. Всё можно сделать немного проще. Но хотелось бы посмотреть на эквивалентную стратегию в hg. Могли бы вы привести аналогичные примеры?
                +4
                У нас разработка происходит примерно так
                1. Создаем папку для ветки
                mkdir mybrahch
                cd mybrahch
                2. Создаем ветку
                hg clone <project_path/URL>
                3. Работаем…
                hg commit -m «Разработано что-то полезное»
                4. Получаем последнюю версию из централизованного репозитория
                hg pull <project_path/URL>
                5. Объединяем
                hg merge
                6. Тестируем…
                7. Если нашли ошибку, идем на п. 3
                8. Обновляем централизованную ветку
                hg push <project_path/URL>
                Преимущества:
                1) в SVN имя ветки должно быть уникальным для всех, в распределенных системах имя ветки локально для разработчика и после объединения и синхронизации про ветку вообще можно забыть.
                2) Git/Mercurial действительно умеет очень просто объединять ветки. Я в первый раз, когда объединил две ветки, а система не задала не единого вопроса, был даже немного напуган и прошелся по всем изменениям, убедившись, что система сделала все правильно.
                Недостатоки:
                1) в Git/Mercurial нельзя извлекать часть репозитория, а только весь репозиторий целиком. Для очень больших проектов это может стать проблемой
                2) в Git/Mercurial плохо работать с бинарными файлами из-за того, что репозиторий в этом случае будет очень быстро расти в размере. Это может тоже быть плохо для веб-проектов.
                SVN и Mercurial можно использовать совместно и я слышал, что так делают. Но подробностей не знаю.
                  +2
                  1. Создаём ветку
                  > svn copy ^/trunk ^/branches/name

                  2. Переключаемся на ветку
                  > svn switch ^/branches/name

                  3. Работаем…
                  > svn commit -m «Разработано что-то полезное»

                  4. Сливаем изменения из ствола в ветку
                  > svn mergeinfo --show-revs eligible ^/trunk
                  123
                  125
                  126
                  > svn merge --accept postpone -r 122:HEAD ^/trunk


                  5. Правим конфликты, если таковые имеются

                  6. Тестируем и комитим результаты слияния
                  > svn commit -m «Слияние trunk 123:126»

                  7. Переключаемся в основную ветку
                  > svn switch ^/trunk

                  8. Сливаем ветку в ствол
                  > svn merge --reintegrate ^/branches/name

                  9. Правим конфликты, но пока их тут никогда небыло и убираем изменения, которые сливать нет необходимости (например версия модуля в maven)

                  10. Тестируем и комитим результаты слияния
                  > svn commit -m «Слияние branches/name»

                  11. Удаляем ветку
                  > svn delete ^/branches/name

                  Шаг 3 автоматизирован.
                  Для шагов 7 и 8 так же есть скрипт.

                  Вижу, что по сравнению с hg действительно приходится делать больше телодвижений:
                  1. Получение версии для слияния
                  2. Комиты результатов слияния (2 шт.)
                    0
                    В hg тоже нужно комитить результаты слияния. Я пропустил этот шаг по ошибке, т.к. GUI объединяет эти два действия в одно. Если точнее, даже три действия — для редактирования конфликтов автоматически запускается Kdiff3 или любая другая объединялка.
                    +1
                    А можно про разрешение конфликтов в Git поподробнее? Лично у меня в SVN большинство правок мержиться нормально, но иногда встает раком при изменении одних и тех же кусков разными людьми. Естественно, такие ситуации решаются только волевым вмешательством и ручным мержем. Ну и иногда у клиента из-под lin рвет башню и он за счет разных переносов строк считает конфликтным весь файл.

                    Я собственно к чему — есть возможность привести пример конфликтов, которые спокойно разрешает git, но не может решить svn? Хочется чужого опыта хлебнуть, а не собственные шишки на рабочих проектах набивать.
                      0
                      для переносов строк выставляйте autoproperties:
                      *.php = svn:eol-style=LF
                        0
                        Либо пользуйтесь параметром --ignore-eol-style при merge
                          +4
                          За совет спасибо. Обязательно попробую. Но это трабла вылезает в худшем случае раз месяц, а то и реже.

                          Меня очень сильно интересует конфликты, которые git хорошо резолвит, а svn не дюжит. Просто большинство историй переходов с svn на git содержит примерно такой сценарий
                          1. Развернули svn
                          2. Криво смержили (не читали мануал)
                          3. Расстроились
                          4. Развернули git
                          5. Смержили правильно
                          6. Заклеймили SVN позором

                          Ну и еще некоторый процент ситуаций, где распределенное хранилище тупо удобнее централизованного. С этим понятно. А вот подтверждению сакральному «git мержит лучше, чем svn» еще не видел.
                            +1
                            В этом то и преимущество git — нет такой необходимости читать документацию. А статьи и высказывания «Ветки в svn — это тихий ужас» уже немного задолбали.
                              +2
                              Вы меня немного не так поняли. Под вторым пунктом я имел ввиду человеческую ошибку, совершенную как следствие начала знакомства с системами контроля версий. Которую человек с некоторой вероятностью совершил бы и работая с git.
                              А документацию читать надо всегда)

                              «Последовательность:
                              1. Эксперимент
                              2. ппц
                              3. Чтение документации

                              неискоренима»(с)
                              0
                              Вот habrahabr.ru/blogs/webdev/120063/#comment_3933032 ещё одна история отказа от svn :(
                                +1
                                Вы описали в точности мою ситуацию (только у меня Mercurial вместо Git). При слиянии в SVN нужно задуматься, сосредоточиться и сделать. А в Git/Mercurial — просто сделать, не приходя в сознание.
                                Я б хотел привести конкретный пример или доказательство, но не могу — давно уже не пользуюсь SVN. Но по «ощущениям» все очевидно практически сразу, нужно пробовать.
                                На Хабре, кстати, есть много хороших статей по hg:
                                habrahabr.ru/blogs/development_tools/108443/
                                habrahabr.ru/blogs/development_tools/108658/
                                habrahabr.ru/blogs/development_tools/108904/
                                habrahabr.ru/blogs/development_tools/109074/
                                habrahabr.ru/blogs/development_tools/109203/ (слияние)
                                habrahabr.ru/blogs/development_tools/109428/
                                  +1
                                  Бегло просмотрел топики. Может не прав, но они говорят об удобстве инструментария git по сравнению с инструментами svn. Этот тезис у меня вопросов не вызывает.
                                  Меня больше волнует вопрос «качества» слияния. Некоторые люди говорят, что с git они реже разрешают конфликты руками. Как я вижу от ручного разрешения конфликтов в git все равно не уйти, но «приятнее» проходят. Правильно?
                                    0
                                    Да, ручных разрешений конфликтов не избежать. Они появляются тогда, когда двое или больше программистов правят одни и те же строчки кода. Если они правят файл в разных местах, то конфликт разрешается автоматически как в Git, так и в SVN, насколько я понял.
                                    Kdiff3 (или другая графическая объединялка) как инструмент слияния конфликтных файлов удобен тем, что показывает 4 панели:
                                    1. Версия файла, с которой вы разошлись (общая для обеих веток)
                                    2. Ваша версия
                                    3. «Другая» версия (из другой ветки)
                                    4. Результат слияния (в который можно вносить любые правки)
                                      0
                                      Не подумайте, что докапываюсь, просто в одном из своих комментариев Вы написали

                                      «Я в первый раз, когда объединил две ветки, а система не задала не единого вопроса, был даже немного напуган и прошелся по всем изменениям, убедившись, что система сделала все правильно.»

                                      Я это прочитал как «если бы я сливал ветки в SVN, то получил бы несколько конфликтов. Но в git всё само решилось». То, что будет конфликт при совместном редактировании одной и той же строчки — тут сомнений нет. Но мне при чтении таких комментариев как у Вас виделась следующая ситуация:

                                      SVN иногда спотыкается не только при одновременном изменении одной и той же строчки, но и некоторых других ситуациях. А git в этих ситуациях не ошибается. Есть что-то такое? Или я неверно интерпретировал Ваши слова?
                                        0
                                        К сожалению, как раз ощущение «не может быть, что оно так просто само все объединило» я рационально подкрепить не могу. Мы с сотрудником неделю работали, каждый над своим клоном, а потом я в GUI нажал на «Pull», «Merge», в визарде понажимал несколько раз на «OK» и вуаля — у меня закомиченная объединенная версия. И субъективно это воспринялось как: «Так, надо все еще раз проверить».
                                        Это субъективное, конечно, ощущение, но вознило почти у всех наших сотрудников, когда они по-одному переходили на hg.
                                        Я совершенно не утверждаю, что SVN хуже объединяет. Но, например, в hg нет ключа '--reintegrate'. Он будет объединять ветки в любую сторону, а потом обратно и везде с минимальным участием человека в процессе.
                                          0
                                          Спасибо за ответ. Как итог — нужно собраться с силами и самому попробовать.
                                      +1
                                      stackoverflow.com/questions/43995/why-is-branching-and-merging-easier-in-mercurial-than-in-subversion
                                      Ссылка из коментариев к одному из топиков.
                              0
                              Ещё интересно, как Git/Mercurial работает с tree conflicts. Это когда, например, в основной ветке фаил удалили, а в рабочей ветке в этот же фаил были внесены изменения.

                              И как дела обстаят с перемещениями фаилов и параллельным изменением их в другой ветке.
                                0
                                Насчет переименования/переноса файлов:
                                — В Mercurial такие операции нужно указывать явно (hg rename, если не ошибаюсь), тогда он будет отслеживать историю и конфликты правильно.
                                — В GIT файлы идентифицируются с помощью SHA-1, в результате, если хэши у файлов совпадают, GIT автоматически считает это одним файлом и ведет общую историю. Это называется «content-addressed storage».
                                Когда я выбирал VCS, я пытался «запутать» Mercurial копированиями, переименованиями и удалениями, но он со всем справился. В самых сложных случаях он спрашивал, удалить файл или оставить, если в одной ветке он редактировался, а в другой — удалился.
                                  0
                                  Ясно. В SVN проблема перемещения в том, что svn move = svn copy & svn delete
                                  Поэтому, при редактировании удалённого фаила, после обновления или слияния старый фаил будет вновь отмечен для добавления, но на новый фаил изменения накатятся, т.е. если надо оставить новый фаил, то ваши изменения уже будут в нём.
                                0
                                Формально говоря это не ветка, а клон репозитория :) Механизм веток в Mercurial есть, но его использование, по-моему, более специфично, например разделение на production и stage. А собственно для разработки, да, удобнее использовать клоны.
                                  0
                                  «для разработки, да, удобнее использовать клоны.» как можно необходимость называть «удобнее»? :-)

                                  Без клонирования вы в принципе не сможете получить себе репозиторий. Это данность, а не удобство.

                                  А вот с бренчами удобно следовать идеологии branch per feature (featurebranches). Это, да, удобство :-)
                                    0
                                    У меня полно на винте репозиториев созданных без клонирования :) Но вот ветки в них создавать не люблю, предпочитаю сделать клона, а потом слить с origin.
                                      0
                                      Ну если доступ есть к фс другого репозитория — тогда да. Но это исключительный случай.

                                      А по поводу клон+слив с origin — ну кому как нравится, меркуриал предоставляет выбор и спасибо ему за это :-) Лично мне нравятся именованные featurebranches
                                        0
                                        Нет, просто репозитории существуют только локально, сначала создаю «origin», а потом его клонирую :). Но вообще да, дело вкуса.По идее бранчи должны быть удобнее хотя бы тем, что не размножается всё, но вот как-то не прижились они у меня для разработки отдельных фич. Даже с именованием как-то трудности возникали :)
                                          0
                                          Кстати, 'hg share' (с включенным плагином) позволяет создать альтернативную рабочую папку (желательно в рамках одного компьютера) и экономит место. Вы комитете в одной папке, а в другой дерево истории тоже обновляется. Так можно иметь один репозиторий и одновременно несколько последних версий разных веток.
                                  0
                                  Почему вы клонирование называете «создаём ветку»?
                                    0
                                    Это специфика Mercurial (в отличе от Git). Каждый клон является «неименованной веткой» (unnamed branch). Именованые ветки для разработки конкретной функциональности в Mercurial создавать не удобно, поскольку имя такой ветки будет существавать всегда. Именованая ветка в mercurial создается для постоянных веток (типа «stable», «develop» и прочее).
                                      0
                                      1. Именованные ветки называть легко и я их создаю для каждого тикета

                                      2. Откуда вы взяли про «неименованные» ветви? После клона вы получаете клон репозитория. Со всеми ветвями. Никаких «неименованных» не существует, вы неправильно трактуете документацию. Unnamed == неименованная ветвь, с дефолтным именем default. И это определение из документации, я считаю, не совсем корректным.

                                      Т.к. «Clone checks out the tip of the default (aka unnamed) branch (see NamedBranches). » — это вот поведение совсем не обязательное. Вы можете не чекаутить tip дефолта. Вы можете просто клонировать и остаться на null ревизии, а ещё через -u rev вы можете чакутнуться на конкретную ревизию или бренч (а не только на unnamed)
                                        0
                                        А как вы справляетесь с тем, что 'hg branches' выдает засоренный список веток, позвольте полюбопытствовать?

                                        По поводу неименованых бренчей я основывался тоже на документации, см. The flow of changes—big picture vs. little. Под неименованными ветками в этом разделе подразумевается короткоживущие ветки, которым специальные имена не дают и их изолируют в отдельном клоне репозитория.
                                        Но, это терминологический спор, сути все равно не меняет. Вы тоже правы.
                                          0
                                          Я закрываю те ветки, работы в которых более не ведутся.

                                          В произвольный момент времени у меня hg branches выводит: default, stable, пару-тройку открытых именованных.
                                            0
                                            «я основывался тоже на документации»

                                            книжка на red-bean давно уже устарела. равно как и wiki на селенике тоже. из hg help pull уже убрали «спорные» моменты (хотя есть вероятность, что их там никогда и не было, я не видел) :-)
                                      +1
                                      Недостаток 1) решается в mercurial модулем subrepo
                                      Недостатка 2) в mercurial нет (по сравнению с Git).
                                        0
                                        Странно, а я всегда считал, что распределенные VCS плохи для работы с бинарными файлами, поскольку требут при клонировании копирования всей истории. При работе с исходнгиками в репозитории храняться сжатые дельты, поэтому он практически не растет. А для бинарных файлов дельты хранить не получиться. В чем тут отличие Mercurial от Git?
                                          0
                                          Если я правильно помню, mercurial имеет более удобный формат хранения бинарных файлов. Но в git есть repack.
                                0
                                Иногда этих костылей вполне хватает и все довольны. Каждому по потребностям.
                                  +1
                                  Программировать тоже можно на P133, но зачем?
                                    0
                                    Вы передергиваете.
                                    Svn и git — это не как P133 и P4.
                                    Это два разных инструмента, развивающиеся по-разному. Хотите используйте, хотите нет.
                                  +5
                                  А какая разница, касаемо описанной темы?
                                    +1
                                    Избежать
                                    Если сливать «в лоб» (sw A, merge A B) то будет очень много конфликтов, которые очень сложно разрешить
                                    ?
                                    +2
                                    git сам состоит из костылей чуть менее, чем полностью, т.к. до сих пор является кучкой скриптов, взаимодействующих через stdout.
                                    Лично я всем советую mercurial + hgsubversion (для прозрачной работы с репозиториями svn) + hg-git (для прозрачной работы с репозиториями git). А если pushить в git и/или svn не нужно, тогда хватит и просто mercurial.
                                      +1
                                      «до сих пор» — а с linux-way идеологией он никогда и не изменится. Пайпы — это правильно же :-)
                                        +2
                                        ящетаю, mercurial является более unix-way, чем git. Обосную:
                                        1) не гадит в stdout по поводу и без (сравним git status и hg status в свежесозданном пустом репозитории)
                                        2) один инструмент (/usr/bin/hg против git, git-receive-pack и git-upload-pack)
                                        3) правильная архитектура — один питоновый (пока?) модуль hg и CLI к нему, против кучки бинарников
                                        Более того, текущая архитектура git не устраивает даже Github, что как бы подтверждает проект libgit2. Не говоря уже о наличии минимум двух реимплементаций git — JGit (pure java) и dulwich (pure python)
                                        Ну и ещё — я ничего не имею против git, как VCS. Star merge — действительно нужная и полезная штука. Но вот интерфейс (UI в том числе) у текущей реализации отвратителен чуть более, чем полностью.
                                          0
                                          Да я шутил изначально :-)

                                          но всё таки с один инструмент vs много инструментов — второе более юниксвейно, ибо специфическая утилита, умеющая хорошо делать что-то одно.
                                            0
                                            я не спорю. просто вспомни, когда последний раз ты вызывал git-upload-pack или git hash-object.
                                              0
                                              никогда! :-))
                                                0
                                                99,9% пользователей git (в т.ч. и фанбоев) ответят точно так же.
                                                зачем в таком случае, пользователю эта утилита?
                                                  0
                                                  С тем же самым лозунгом можно выпилить половину гнусных утилит из линукса :-)
                                                    0
                                                    неа. эта половина утилок рассчитана на то, что ими будет пользоваться юзер, а не другие утилки. а в git половина команд — исключительно для внутреннего применения. но под ногами они путаются.
                                                    ну вот в mercurial есть семейство команд debug*. они слегка запрятаны, да, но они есть. Но они вот почему-то не вызываются другими командами, а используются юзером.
                                                +1
                                                Эти комманды — тяжелое наследие дизайна Git. Предполагалось изночально что git будет что-то вроде версионной базы данных и поверх git можно будет построить систему контроля версий (кто-нибудь помнит cogito?). Так вот — база данных гит состояла из кучки шелл скриптов которые должны вызываться твоей программой.

                                                Но с тех пор произошло несколько коррекций
                                                1) Git это не база данных а система контроля версий
                                                2) API по управлению git репозиторием основанной на шелле — зло

                                                Насчет второго — было несколько попыток сконвертировать git в библиотеку с нормальными баиндингами для других языков. Несколько попыток потерпели fail. Но вот последняя нормально развивается — github.com/libgit2 Будем надеятся что в скором времени git перейдет на нее, а комманды типа hash-object уйду в нибытие (в смысле из шелла в API).
                                                +4
                                                hg — утилита, которая хорошо делает что-то одно — управляет версиями :)
                                                  +2
                                                  резонно, да ))
                                            +1
                                            Я при выборе VCS остановился на Mercurial по следующим, возможно субъективным, причинам:
                                            1. В Git с поддержкой Windows довольно плохо.
                                            2. К Mercurial есть плагин позволяющий хранить временные штемпели отдельных файлов — специфика конкретного проекта.
                                            3. Ревизии Git идентифицируются хэш-идентификаторам, что не удобно для кратковременного запоминания (пусть даже и части id). В Меркуриале идентификатор состоит из локального номера и глобального идентификатора (типа 143:ab46778a...), и в 99% случаях для работы с репозиторием достаточно запоминать номера.
                                            Сравните,
                                            git diff as5675ff:cfg7с261
                                            и
                                            hg diff 100:145
                                            А так, оба инструмента очень хороши.
                                              +2
                                              К Mercurial есть плагин
                                              да вообще сам факт того, что для hg можно писать полноценные плагины, есть killer feature
                                              В Меркуриале идентификатор состоит из локального номера и глобального идентификатора
                                              кстатида, подтверждаю — удобно.
                                                0
                                                пункт 3 очень важный, конечно. зачем запоминать номера ревизий?
                                            0
                                            опубликовать ссылку на проблемное место на тестовом хосте в задаче (в мегаплане или другом тасктрекере)

                                            Не понял, что за проблемное место и откуда оно взялось?

                                            А хуками для автоматического деплоя на все эти *.ПРОЕКТ.КЛИЕНТ.devserver.ru рекомендуете пользоваться или ручками заливать?
                                              +1
                                              > Не понял, что за проблемное место и откуда оно взялось?
                                              ссылка на страницу с исправлением/доработкой

                                              > А хуками для автоматического деплоя на все эти *.ПРОЕКТ.КЛИЕНТ.devserver.ru рекомендуете пользоваться или ручками заливать?
                                              правильно настроенные хуки в стократ лучше ручек
                                              +5
                                              указывать -r 101:167 давно не нужно, нужно использовать --reintegrate
                                              • UFO just landed and posted this here
                                                • UFO just landed and posted this here
                                                    0
                                                    svnadmin upgrade

                                                    rtfm 8)
                                                    • UFO just landed and posted this here
                                                  +3
                                                  Насчет reintegrate верно написали выше (хотя указывать ревизии при мерже в бранч, думаю, надо): вливать ветку в транк все-таки обязательно нужно с помощью опции --reintegrate, а не просто merge: причина, синтаксис.
                                                    0
                                                    --reintegrate, если в ветке не продолжится разработка после этого
                                                    +3
                                                    Неплохая вводная статья, особенно часть, касающаяся развертывания. Кстати, её можно было бы расширить до отдельной заметки.

                                                    Касательно ветвления, я вот тут делал перевод неплохой статьи про подход «одна ветка на одну задачу»: scm-notes.blogspot.com/2010/09/branch-per-task-workflow-explained.html

                                                    И вообще вот здесь собрал много ссылок на тему ветвления и не только:
                                                    scm-notes.blogspot.com/p/software-configuration-management.html
                                                      +2
                                                      Почему в разделе ВЕБ-разработки? SVN используется в значительно больших местах.
                                                        0
                                                        > Особенностью современной веб разработки является полное отсутствие планирования при создании, поддержке и выкатке проектов.

                                                        Потому что речь идет конкретно о применении VCS в веб-разработке.
                                                        +2
                                                        При слитии trunk в ветку необязательно указывать ревизию последнего слития, достаточно указать ревизию создания ветки.
                                                        В дополнении к уже сказанному про reintegrate: если есть необходимость поддерживать ветку дальше, то необходимо заблокировать ревизию:
                                                        > svn merge --reintegrate @branch
                                                        > svn ci -m "..."
                                                        Rev: 123
                                                        > svn sw @branch
                                                        > svn merge --record-only -c 123 @trunk
                                                        > svn ci -m "..."
                                                          0
                                                          Можно поподробнее? Не пойму что именно произойдет и как это повлияет на дальнейшую разработку.
                                                            +2
                                                            «Once you have performed a reintegrate merge you should not continue to use it for development. The reason for this is that if you try to resynchronize your existing branch from trunk later on, merge tracking will see your reintegration as a trunk change that has not yet been merged into the branch, and will try to merge the branch-to-trunk merge back into the branch! The solution to this is simply to create a new branch from trunk to continue the next phase of your development.»

                                                            Так сказано по ссылке приведённой в habrahabr.ru/blogs/webdev/120063/#comment_3932020

                                                            Тем не менее параметр --record-only просто устанавливает в свойство svn:mergeinfo ревизию транка, в которой были слиты изменения из ветки, без слития самих изменений и в дальнейшем merge не будет учитывать эту ревизию при слитии транка в ветку.

                                                            > cd my-calc-branch
                                                            > svn propget svn:mergeinfo .
                                                            /trunk:1680-3305

                                                            # Let's make the metadata list r3328 as already merged.
                                                            > svn merge -c 3328 --record-only ^/calc/trunk
                                                            > svn status
                                                            M .

                                                            > svn propget svn:mergeinfo .
                                                            /trunk:1680-3305,3328

                                                            > svn commit -m "Block r3328 from being merged to the branch."

                                                            Пример взят по ссылке svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html которую я крайне рекомендую для ознакомления всем, кто так или иначе работает с ветками SVN.
                                                              0
                                                              Спасибо, теперь понятно. Подобные действия обычно производил ручной правкой svn:mergeinfo.
                                                                0
                                                                Рад, что чем-то помог. Но всё-так советую почитать документацию и вполне возможно, что найдёте ещё много полезного.
                                                                  0
                                                                  Спасибо, но уже поздно читать документацию по svn, т.к. мы намучились с ветками в нем и уже начали переход на hg.
                                                          0
                                                          Ветка создается очень просто:

                                                          svn copy svn://svnserver.ru/КЛИЕНТ/ПРОЕКТ/trunk svn://svnserver.ru/КЛИЕНТ/ПРОЕКТ/branches/НАЗВАНИЕ_ВЕТКИ -m 'КАКОЙ ТО КОММЕНТАРИЙ О ВЕТКЕ'


                                                          Позабавило :) по сравнению с
                                                          git branch НАЗВАНИЕ_ВЕТКИ
                                                            +4
                                                            svn copy ^/trunk ^/branches/branch_name
                                                            Согласитесь, не намного сложнее?

                                                            Да и никто не мешает сделать скрипт, наподобии:
                                                            svn copy ^/trunk ^/branches/%1

                                                            И вызывать его:
                                                            svn_branch НАЗВАНИЕ_ВЕТКИ
                                                            +2
                                                            а вот ещё модель ветвления nvie.com/posts/a-successful-git-branching-model/
                                                              0
                                                              Особенностью современной веб разработки является полное отсутствие планирования при создании, поддержке и выкатке проектов.


                                                              Дальше можно не читать.

                                                              Only users with full accounts can post comments. Log in, please.