Состоялся релиз subversion 1.7

    После двух с половиной лет разработки свет увидел новый major релиз централизованной системы управления версиями subversion: что нового, видео обзор.


    Нумерованные ошибки и предупреждения


    Теперь в случае ошибки нет необходимости гуглить ее сложносоставной текст — достаточно номера — как у компиляторов или wix.

    Только одна папка .svn в корне


    Начиная с версии 1.7 subversion не будет создавать в каждой папке свою подпапку ".svn" — теперь эта папка создается только в корне рабочей копии.

    Ускорение работы по HTTP


    За счет отказа от полной совместимости с редко используемым WebDAV и использовании упрощенного протокола, называемого авторами HTTPv2.

    Новая утилита svnrdump


    Позволяет сделать dump удаленного репозитория не имея к нему админского доступа.

    Новая команда svn patch


    Позволят применить к рабочей копии патч в формате unidiff.
    Метки:
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 299
    • +35
      > Начиная с версии 1.7 subversion не будет создавать в каждой папке свою подпапку ".svn"
      ура :)
      > Позволят применить к рабочей копии патч в формате unidiff.
      тоже круто.
      • +27
        >>Только одна папка .svn в корне
        Моя мечта сбылась.
        • +26
          >> Только одна папка .svn в корне

          Unbelievable
          • +9
            Да нет, одна. Уже проверил.
        • –26
          Им еще кто-то пользуется? (когда есть Git и Mercurial)
          • +47
            я пользуюсь
            • +8
              А Git либо Mercurial пробовали?
              • 0
                к сожелению не приходилось, но возможно в ближайшем будущем, если команда решит, будем пробовать :)
                • +6
                  Попробовать можно дома и без решения команды, а потом продвигать прогресс внутри команды… кто-то же должен это делать ;)

                  Кстати эти графики тоже дают повод задуматься:
                  www.google.com/trends?q=git%2C+svn%2C+mercurial&ctab=0&geo=all&date=all&sort=0
                  • +5
                    я вот понять не могу, что ж такого в этом git или mercurial?
                    • 0
                      Например эту «фичу» они умели изначально :)

                      >Начиная с версии 1.7 subversion не будет создавать в каждой папке свою подпапку ".svn"
                      >теперь эта папка создается только в корне рабочей копии.

                      К тому же там намного более удобно делать Merge.

                      Но самое главное отличии от SBN — они децентрализованные.
                      Это значит что ты (и все твои напарники) могут продолжать совершенно спокойно работать даже если сам сервер с репозиторием (или коннект к нему) лежит.

                      p.s. Совсем не всегда хорошей идеей является хранение исходников продукта в стране где власть может плевать на законы :) + команда разработчиков частенько бывает разделена океанами.
                      • +7
                        В SVN тоже можно работать, пока лежит сервер.
                        Все равно, и там и там необходимо потом мержить то, что написано.
                        • 0
                          Git/Hg уменьшают количество шагов, которые нужно сделать. Понятно, что в SVN можно сделать всё, что умеют Git/Hg: настроить локальное зеркало удаленного репозитория, делать и мерджить бранчи, но в Git/Hg это просто удобнее. Можно работать над какой-то фичей, а если срочно что-то нужно поправить в текущей версии, но фича ещё не готова, просто делаешь update к соответствующему changeset, исправляешь, комитишь, делаешь update к своей работе, продолжаешь работать, и это всё делается очень быстро и просто.
                          • 0
                            Больше 10 лет работали с CVS и SVN, потом пару лет на Git, но в конце-концов не выдержали — когда история накопилась, он стал дико тормозным (наверное потому что у нас Windows?), перешли на Fossil (http://fossil-scm.org/) — компактно, быстро, всё-в-одном.
                            • 0
                              А что в нём такого особенного?
                              • 0
                                Ничего особенного, почти такой же как и все современные scm. Просто меньше, быстрее, встроенный веб-интерфейс с трекером.
                            • +1
                              Почему меньше, наоборот больше: сначала надо сделать коммит к себе, а потом push на удаленный репозиторий. А в svn сразу на сервер. Так что Вы лукавите…
                            • +1
                              Я на прошлой неделе ругался, когда с сервером svn что-то происзходило, а мне надо было вытащить 1 сраный файл из прошлой ревизии. При пользовании git-ом на других проектах таки проблем небыло никогда.
                              • –4
                                А как вытянуть 1 файл в гите при неработающем сервере? Откуда его взять? Он же должен где-то храниться.
                                • 0
                                  в локальном репе взять, или взять из репа другоко члена команды…
                                  • –3
                                    если он есть локально — я могу его скопировать вообще без системы контроля версий.
                                    • +5
                                      Вы очевидно не понимаете. Гит и другие децентрализированые системы контроля версий держат историю локально. Файла с предыдущей версии нету, но git/hg вам его с удовольтвием предоставлят на запрос без шуршания по сети.
                                      • 0
                                        ок, и как тогда получить последнюю версию файла? с последними изменениями, сделанными не мной?
                                        • +1
                                          git log --pretty=oneline path/to/file — видите историю изменений в данном файле. соответсвенно копируете себе хеш комита, который вам подходит.

                                          потом делаете git checkout <хешкомита> path/to/file

                                          и получаете нужную версию файла.

                                          --pretty=oneline — формат отображения истории, таков для данной задачи наверное самый удобный.
                                          • +2
                                            Кхм…
                                            > а мне надо было вытащить 1 сраный файл из прошлой ревизии
                                            > прошлой

                                            Все началось с небходимости посмотреть прошлую ревизию, закончилось «как получить последнюю вресию файла»
                                    • 0
                                      У соседа по комнате
                                      • –3
                                        Где гарантия, что у него последняя версия?
                                        • +5
                                          А где гарантия, что на «централизованном» сервере последняя версия?
                                          • –3
                                            На сервере SVN всегда последняя закомиченная версия.
                                            Как в Git/Hg держать актуальной рабочую копию при не работающем центральном (ну или каком-то корневом сервере в децентрализованной системе) сервере?
                                            • 0
                                              «Центральный» реп можно поднять вместе с коммитами и ветками из любой локальной копии.
                                              Но возьмем, к примеру, случай, когда разработчик работает над некой фичей. Он работает в отдельной ветке, текущее состояние «центрального» репа ему ни к чему — у него своя задача. Предположим, падает этот самый «центральный» реп. Как дальше работать пользователю svn? Да никак — ждать, пока поднимут сервер, или копить коммит в пару мегабайт текста. Как дальше работать пользователю git? Как и раньше работал — о падении «центрального» репозитория он узнает только после того как доделает фичу, сольет ветку с ней в главную и попытается залить ее на упавший реп. И даже если до этого момента реп не починят, он пожмет плечами, создаст новую ветку и начнет работать над новой фичей.
                                              Предположим, что пользователя snv вполне устраивает ситуация с коммитом в несколько мегабайт. Он продолжает дальше работать, не делая коммитов, и тут обнаруживает ошибку в главной ветке (которая влияет не только на его фичу, но и на все прочее). Ему нужно переключиться в центральную ветку, сделать фикс, переключиться обратно. А он не может этого сделать, т.к. репозиторий лежит. Что в этом случае сделает пользователь git? Переключится на главную ветку (она у него есть локально), сделает фикс, попытается пушнуть все это в центральный реп, скажет: «Ой, центральный реп лежит», переключится в свою рабочую ветку, смержит главную, и продолжит работать. А фиксы зальет на сервер тогда, когда его поднимут.
                                              • 0
                                                Это все хорошо, но репозитории не то чтобы часто падают :). Учитывая что в Subversion есть довольно простая в настройке машинерия для создания резервного репозитория с синхронизацией каждого коммита.
                                                • 0
                                                  Хм, возможно вы правы.
                                                  Единственное, не пойму, почему у всех такая проблема, как лежит сервер такая актуальная.

                                                  У нас за 4 года svn был недоступен лишь один раз, пол часа, когда обновлялись DNS.
                                                  • 0
                                                    Да из банальных даже примеров: я работаю дома, упал интернет, или я забыл его оплатить. У меня завтра дэдлайн, и я пишу код в метро. Ну или просто из-за какой-нибудь неведомой ебаной фигни покрашился реп (для свн тут вообще катастрофа, не так ли?).

                                                    Но на самом деле, эта проблема сильно теоретическая. Гораздо более насущной является проблема переключения в другую ветку посреди коммита и внесения там изменений. У svn, насколько я знаю, аналога команды stash нет.
                                                    • –1
                                                      И какая польза проекту от такого коммита в метро? Кто им может воспользоваться?

                                                      Покрашился реп? Ну, обычные регулярные бекапы (даже бекап на коммит) никто не отменял, с таким успехом — какая гарантия, что кто-то «второй» держит у себя полную копию git/hg репозитария?

                                                      Аналога команды stash нет, но если нужно поправить другую ветку, почему нельзя сделать:

                                                      svn copy CURRENT_URL_OF_WORKING_COPY SOME_BRANCH
                                                      svn switch SOME_BRANCH
                                                      svn commit -m «work in progress»
                                                      svn switch WHATEVER_I_WAS_WORKING_ON_BEFORE

                                                      А если, как говорят многие пользователи git/hg, сервер недоступен/лежит, то и смысла от этого коммита для проекта — ноль.

                                                      Опять же, если есть необходимость править несколько веток одновременно, которые нужны только мне самому и локально… хм, зачем тут система контроля версий для коллективной разработки?
                                                      • +1
                                                        >И какая польза проекту от такого коммита в метро? Кто им может воспользоваться?
                                                        Я выйду из метро, дойду до интернета и запушу все в центральный реп. При этом у меня с собой в метро будут все ветки, и я смогу нормально коммитить, а не набирать гигантских размеров коммит.

                                                        > какая гарантия, что кто-то «второй» держит у себя полную копию git/hg репозитария?
                                                        Все разработчики в сумме держат полную и атуальную версию репа. Восстанавливаем «центральный» реп из локального от любого автора, отсальные делают в него пуш — вуаля, полностью актуальный реп со всеми коммитами.

                                                        >Аналога команды stash нет, но если нужно поправить другую ветку, почему нельзя сделать:
                                                        Я говорил не об этом. Предположим, вы делаете некоторую фичу и обнаруживаете баг в главной ветке. Вам нужно переключиться в главную ветку и поправить этот баг. Но у вас есть незакоммиченные изменения, которые коммитить сейчас нельзя, т.к. код банально не дописан и не проверен. В git вы делаете stash, переключаете ветку, делаете фикс, переключаетесь обратно, делаете stash apply. Как вы разрулите это в svn.

                                                        >А если, как говорят многие пользователи git/hg, сервер недоступен/лежит, то и смысла от этого коммита для проекта — ноль.
                                                        Этот коммит зальется в центральный реп, как только оный станет доступен. И это могут быть несколько красивых коммитов, а не один толстый с тучей правок.

                                                        Я вижу, что вы не совсем понимаете или совсем не понимаете смысл работы в ветках…
                                                        • 0
                                                          > Как вы разрулите это в svn.
                                                          Создам еще одну рабочую копию.

                                                          > И это могут быть несколько красивых коммитов
                                                          В svn это может быть несколько рабочих копий => несколько коммитов (менее удобно, но все же).
                                                          • +1
                                                            Это называется «извращения», это уже о другом…
                                                            • 0
                                                              Если сервер лежит при этом (невозможно сделать checkout), то просто скопирую рабочую копию, откачу в ней все изменения, и внесу нужные исправления.

                                                              > «извращения»
                                                              Скорее особенности, но основной смысл в том, что и с svn можно некоторое время работать без связи с сервером.

                                                              Для мелких изменений (поправить один файл) в svn создавать отдельную глобальную ветку нецелесообразно, гораздо проще ограничиться еще одной рабочей копией (в этом случае её можно сравнить с локальными ветками в гите).
                                                              • 0
                                                                >Если сервер лежит при этом (невозможно сделать checkout), то просто скопирую рабочую копию, откачу в ней все изменения, и внесу нужные исправления.
                                                                И как потом эти внесенные изменения потом перенести в вашу рабочую копию? Вы совершенно не поняли, о чем я. И непонимание это кроется именно в особенностях работы с svn. Я говорю о ситуации (довольно стандартной для git), когда разработчик разрабатывает фичу в отдельной ветке, чтобы не засорять develop или master ветки. В таком случае ваш план выглядит именно как извращение — ради правки в другой ветке создавать отдельную рабочую копию. Да и вообще создание второй рабочей копии выглядит как извращение, откровенно говоря, в любом случае.
                                                                • 0
                                                                  > И как потом эти внесенные изменения потом перенести в вашу рабочую копию?

                                                                  Будет 2 рабочие копии, основанные на одной ревизии: (1) основная, (2) фикс. Коммитим (2), обновляем (1), коммитим (1), удаляем (2), если не нужен.

                                                                  > Я говорю о ситуации (довольно стандартной для git), когда разработчик разрабатывает фичу в отдельной ветке, чтобы не засорять develop или master ветки.

                                                                  В этом случае у него просто будет 2 рабочих копии (или больше если фич много). В конечном счете они все вольются в trunk и, возможно, будут удалены из репозитория. Неудобно, если фич много, но часто ли один разработчик параллельно разрабатывает много фич? ИМХО, 2-3-4 рабочих копии вполне нормально.

                                                                  > В таком случае ваш план выглядит именно как извращение — ради правки в другой ветке создавать отдельную рабочую копию.

                                                                  Нет, не извращение — особенность. Я ведь тоже могу сказать, что полностью извлекать себе весь репозиторий ради исправления одной строки в одном файле — это извращение…
                                                                  • 0
                                                                    Вы опять не поняли ситуацию…
                                                                    Вы разрабатываете фичу. Делаете это в отдельной ветке. В этой фиче у вас уже сделано несколько коммитов, которых еще нет в главной ветке. И тут в главной ветке вы замечаете ошибку. Ошибка мешает вашей дальнейшей разработке. ее нужно поправить. Но править в вашей рабочей ветке нельзя, т.е. этот фикс не попадет в мастер-ветку до окончания разработки фичи, а значит не попадет и к остальным разработчикам и в релиз (если он состоится до завершения разработки фичи).

                                                                    Я говорю с вами и натыкаюсь на стену непонимания. Вы, судя по всему, совершенно не понимаете принципов работы в ветках или принципов работы git`а…
                                                                    • 0
                                                                      В этом случае нужно внести изменения в мастер ветку (в другой рабочей копии) и потом влить их в вашу ветку или же создать отдельную ветку для фикса.
                                                          • –2
                                                            И что делать, если кто-то сломает мои «несколько красивых коммитов» по середине своей цепочкой из ста коммитов?
                                                            • 0
                                                              «Посредине» ее никто не сломает. Прежде чем залить свою цепочку коммитов вы все равно сделаете пулл с сервера. Эти сто коммитов просто встанут перед вашими.

                                                              На самом деле, все ооочень красиво и ооочень удобно. Ваши потуги доказать, что «в гите все так же плохо» ни к чему не приведут. Правда.
                                                      • 0
                                                        Все зависит от админов и надежности связи, у нас часто бывало, что svn или tfs недоступны и работать или просто трудно, или невозможно…
                                                        • 0
                                                          Это да, пока все работающие сидят в одной комнате.

                                                          Как только они начинают перемещаться по шарику, оказываться в местах где интернет через gprs и эпизодически, git становится сильно лучше.

                                                        • –2
                                                          Похоже, что понять всю силу и преимущество git можно только если наш svn-сервер будет постоянна падать. За последние 3 года, у нас такого не было ни разу. Все эти примеры из разряда: а что вы будите делать, если вам комп накроется? Сидеть и ждать?! А пользователь git сделает brache и продолжит работу! :)))
                                                          Вот удобство использования в повседневной работе, простота merge-й — это да, есть над чем задуматься.
                                                          • +1
                                                            На самом деле да, возможность работы без центрального сервера лично для меня далеко не самая главная причина перехода с svn.

                                                            Основные причины:
                                                            1) Лучшая защита от дурака. C git гораздо сложнее забыть добавить файл в индекс или потерять свои изменения. Однажды в svn во время мерджа по ошибке ввел tf вместо mf — потерял довольно большой кусок кода, восстановить не смог (да, я знаю, что я сам криворукий дебил и меня к компьютеру вообще подпускать нельзя). В git же на момент pull все локальные изменения всегда закоммичены и их всегда можно восстановить.
                                                            2) Более удобная работа с ветками. Про это уже сказали
                                                            3) git stash. Тоже упоминался
                                                            4) git автоматически распознает переименования, перемещения и удаления файлов в ФС без использования собственных комманд
                                                            5) github
                                                            6) Быстрый просмотр истории, переключение между ветками, чекаут отдельных ревизий — не нужно идти за этим на сервер
                                                            7) Более чистая рабочая директория. Нет отдельных папок для веток и тегов, всего одна папка .git (рад что в .svn теперь также)
                                                            • 0
                                                              Скажите, а у hg такие же преимущества или есть ещё что-то?
                                                              • 0
                                                                честно говоря не в курсе, с hg практически не работал
                                                                • 0
                                                                  да. практически все (кроме п. 5, но bitbucket всё равно не ушёл далеко от GH) перечисленные в предыдущем комменте пункты касаются любой DVCS.
                                                              • +1
                                                                Понять всю силу и преимущество git можно только если вы им попользуетесь. За последний год когда я пользовался Git, я ни разу не смотрел в сторону svn.

                                                                Единственно когда Git не работает — это большие репозитории, когда размер истории больше чем несколько гигабайт.
                                                            • 0
                                                              > На сервере SVN всегда последняя закомиченная версия.
                                                              Согласен. Но если сервер не работает, то Вы этот файл и не получите, кроме как простым копированием. А если вам надо много файлов? А если вам надо целый коммит соседа? Как вы без центрального сервера обменяетесь историей при использовании SVN?

                                                              А с git/hg ситуация иная. Последней версии файла вообще не существует, как и понятия актуальной рабочей копии. Последняя закомиченная версия есть только в конкретном репозитории.
                                                              • –1
                                                                > Последней версии файла вообще не существует

                                                                А что релизить-то будем? Каждый ковыряется в своей песочнице, лепит свои фичи… что-то тут не то.
                                                                • +2
                                                                  Два человека правили один файл. Оба сделали коммиты. Вопрос: у кого из них в репозитории файл последней версии?
                                                                  • –3
                                                                    Вы не путаете репозитарий и рабочую копию?

                                                                    Если они правили пересекающиеся места — второй не сможет закомитить, прийдется сперва сделать апдейт, потом смержить и закомитить.

                                                                    Первому тоже, чтобы обновить рабочую копию необходимо сделать update.

                                                                    В любом случае, перед началом работы необходимо делать update, независимо, какой системой контроля пользоваться.
                                                                    • +2
                                                                      Вы говорите о SVN, а я про Git/Hg. В Git/Hg я могу сделать хоть сотню коммитов. Проблема возникнет только тогда, когда они попытаются обновить историю на одном и том же сервере с помощью push.
                                                                      • 0
                                                                        Зачем делать сотню локальных коммитов?

                                                                        Чем реже и чем больше размер коммита в trunk (в вашем случае — это когда вы будете делать push сотни локальных коммитов) — тем сложнее и дольше это все мержить.
                                                                        • +1
                                                                          Потому что человек этими коммитами разделил сделанные им изменения на более мелкие части, каждая из которых логически замкнута, или он не имел доступа к центральному серверу некоторое время.
                                                                  • +2
                                                                    В Git/Mercurial каждая рабочая копия и есть полноценный репозитарий. Потому два разработчика могут спокойно обмениваться коммитами без какого-либо центрального сервера.

                                                                    Что касается ответа на вопрос:
                                                                    > А что релизить-то будем? Каждый ковыряется в своей песочнице, лепит
                                                                    > свои фичи… что-то тут не то.

                                                                    Вы представляете как устроен процесс разработки, например, ядра Linux? Упрощённо это происходит так. Есть много разработчиков, которые пишут код, фиксят баги. Потом полученные коммиты присылаются людям, отвественным за определённые области в ядре. После review, тестов и прочего ответственные включают или не включают конкретные коммиты в свои основные бранчи. И уже после этого Торвалдс выбирает нужные коммиты из репозиториев этих ответственных за подсистемы и включает в свою основную ветвь. В определённый момент принимается решение и выпускается новая версия ядра.

                                                                    В итоге что имеем: нет никакого центрального репозитория, копошится куча народу, каждый в своей песочнице. Но тем не менее. Релиз ядра — это просто состояние основной ветки в репозитории Линуса Торвалдса в определённый момент времени.

                                                                    Так что и с любым другим проектом — просто конкретный репозиторий (например, репозиторий тимлида) мы объявляем центральным и из него берём код для релизов.

                                                                    P.S. На самом деле часто центральными репами являются bare repos, но сути это не меняет.
                                                        • 0
                                                          В том то и кайф децентрализации — все изменения доступны локально.
                                                          git checkout… — и все.
                                                          • 0
                                                            В git нет понятия сервера. У каждого из членов команды есть своя копия всего репозитория. Некоторые локальные ветки могут ссылатся на ветки на удаленных машинах, но все операции (коммиты, просмотр истории, ветвления и слияния — все кроме синхронизации локальных и удаленных веток) выполняются с локальным репозиторием
                                                            • –2
                                                              Отлично. А мне-то от Системы Контроля Версий только синхронизация и нужна была…
                                                              • +1
                                                                Если вы:
                                                                1) Никогда не просматриваете историю изменений
                                                                2) Не пользуетесь ветками
                                                                3) Никогда не откатываете свои или чужие изменения

                                                                то вам и система контроля версий-то в принципе не нужна. Хватит и diff+patch. Но я что-то сомневаюсь, что вам действительно нужна только синхронизация
                                                                • –3
                                                                  1) Без синхронизации с сервером локальная история изменений меня не интересует.

                                                                  2) Использую, когда это необходимо

                                                                  3) Откатываю.
                                                                  • +1
                                                                    1) У вас есть не только локальная история (ваши изменения) но и полная история всех изменений до времени последнего pullа. Чтобы посмотреть историю, вам не надо обращаться к центральному серверу, вся история есть уже у вас на машине. Просмотр истории в git/hg банально быстрее.

                                                                    1-2-3) Выясняется, что не только синхронизация нужна

                                                                    Да и в целом по поводу синхронизации. Если у вас по каким-то причинам нет доступа к центральному svn-серверу, у вас нет никакой возможности передать код коллегам. В git же вы в таком случае можете добавить репозиторий своего коллеги себе как remote и синхронизироваться напрямую с ним.
                                                      • 0
                                                        Каждому своё. git хорош для стартапов, небольших комманд, опен-соурса. А вот например в мире больших корпораций мысль о том что исходники могут быть «размазаны» по большому числу компьютеров, а не храниться централизовано на сервере — вызывает панику. Потому здесь лучше прижились svn и TFS.
                                                        • +4
                                                          Странный аргумент. По пачке рабочих копий на разных машинах — это не «размазаны»? Или Вы об отсутствии центрального сервера? Так его можно поставить и для Гита/Меркуриала, какие проблемы…
                                                          • +1
                                                            Разные механизмы работы. При централизованных системах все исходники всегда на центральном сервере. При этом ни один программист не может надолго «уйти в подвал» или работать с каким-то своим локальным репозиторием. Все стараются почаще комититься\апдейтиться.
                                                            В результате:
                                                            -в одном месте видно кто и что сделал
                                                            -в любой момент можно уволить кого-угодно — много кода не пропадёт.
                                                            -можно легко пережить «смерть» любого рабочего компьютера (а в больших коммандах это бывает часто)
                                                            -удобно принимать административные решения типа «на эту ветку мы забьём, а эти две сольём»
                                                            -легко кому-то запретить доступ куда-то

                                                            Центральный сервер Гита решает проблему только частично. Им можно пользоваться, а можно и забить, даже если он есть :) — тут уж чисто административные меры можно принимать для борьбы с этим.
                                                            • 0
                                                              Все это какие-то не менее странные подробности.

                                                              Результатом работы программиста является не ченж-лист, а закрытый таск — тот факт, что промежуточные коммиты хранятся на их машинах, а не на центральном сервере, не является проблемой, т.к. это всего лишь кусочек выполнения таска, который в таком виде никому не нужен.

                                                              Кто и что сделал так же оценивается по закрытым таскам, а не по числу коммитов. Да и что это за метрика такая: человек, который на таск делает 100 коммитов продуктивнее, чем тот, кто делает один?

                                                              Т.к. таски при нормальном режиме работы редко длятся больше двух дней, а на рабочих машинах у многих стоит рейд, то потеря данных в результате смерти машины — достаточно минорный риск: не больший по затратам времени и сил, чем, собственно, замена рабочей машины.

                                                              При наличии центрального репо ветки так же поддаются контролю.

                                                              Неудобство запрета доступа на конкретные части проекта — да, это недостаток вышеупомянутых систем, но к размазанности он относится слабо по-моему.

                                                              Ну и наконец, нет, Вы не можете уволить кого-угодно в любой момент, на это нужен месяц, а за это время можно без проблем залить недостающие изменения куда-либо.
                                                              • +3
                                                                Я не буду продолжать спор так как не очень много работал с децентрализованными системами. Может быть Вы и правы, а я чего-то не понимаю.
                                                                Но вот Вы знаете много крупных (от нескольких десятков человек и выше) IT-фирм, использующих штатно git\mercurial, а не что-то централизованное? Вот в радиусе моей видимости соотношение где-то 10:1 в пользу svn\tfs. Не знаю, может случайность такая. Но мне кажется, что в большой фирме степень бардака и так большая а еще и увеличивать её исходниками, разбросанными по разным компьютерам — себе дороже.
                                                                • +1
                                                                  Я знаю фирмы, где используется не Svn, где Svn комбинируется с другими системами (Git или Mercurial). Но оглянитесь: некоторые фирмы до сих пор используют CC, VSS и CVS. Крупные IT-фирмы на то и крупные, чтобы плестись в хвосте эволюции — у них стоимость внедрения новых решений куда выше, чем у средних и мелких — а ресурсы точно так же выжимаются по максимуму, и найти силы на общий переход, да еще и со спорными преимуществами, бывает просто невозможно.

                                                                  Я ни в коей мере не пытаюсь в этом споре доказать, что Svn хуже (ниже я написал немало комментариев как в его защиту, так и против него), но ожидать, что мерилом его устарелости будут ведущие игроки рынка точно не приходится — им просто не интересно и не выгодно проверять на себе новые решения.
                                                          • +6
                                                            >Каждому своё. git хорош для стартапов, небольших комманд, опен-соурса.
                                                            ядро линукса или самба это стартапы с маленькой командой?
                                                            • +6
                                                              это опен-соурс. видите там — в конце предложения? :)
                                                            • +1
                                                              Есть «центральный» репозиторий, в котором хранятся результаты работы всех авторов. Есть локальные репозитории у каждого из авторов, которые отличаются от центрального только наличием изменений и веток, необходимых в данный момент только этому автору (например, фича, над которой работает только он). В случае необходимости это все сливается в «центральный» реп. Где тут размазанность?
                                                              Более того — при падении «центрального» репозитория его можно будет восстановить вместе с коммитами и ветками из локальной копии любого автора. А авторы смогут спокойно работать даже при упавшей сети или умершем «централном» репозитории, не делая вообще никаких дополнительных действий.

                                                              «Центральный» я пишу в кавычках, потому что у git такого понятия нет. Есть удаленные репозитории, коих к локальному можно подключить хоть сто.
                                                              • 0
                                                                А еще есть менеджер, который должен понимать кто что делает и в каком состоянии текущая задача каждого человека. А ну ка расскажите, как это сделать в децентрализованной системе? Без центрального сервера — вообще никак. С ним — только с определенной степенью точности — «Вася 3 дня назад закончил задачу такую-то, а щас хрен-его знает чем занимается».
                                                                Что-что? Спрашивать устно и верить людям на слово? :)
                                                                • 0
                                                                  Если в команде такие разработчики, за которыми нужен глаз да глаз, можно все ветки в конце дня (например) пушить в «центральный» репозиторий.
                                                                  • +1
                                                                    А еще лучше — уволить таких разработчиков к чертям.
                                                                    • +3
                                                                      А заодно с ними и менеджера, который считает наличие коммитов, содержимое которых он все равно не в состоянии понять, признаком прогресса по поставленной задаче :)
                                                                      • 0
                                                                        Ну, менеджера, который не в состоянии понять содержание коммита в любом случае стоит гнать, независимо от используемой системы управления версиями. Речь о том, что в централизованной системе у менеджера хотя бы есть возможность эти коммиты видеть в реал-тайме. Вот бывает ставит заказчик задачу: ускорить быстродействие на 400%. При децентрализованной системе работы эта задача уйдет программеру и он её не пушнет на центральный сервак, пока не выполнит полностью (пусть это займет 4 дня). В централизованной — за 4 дня может быть сделано 20 коммитов с комментами типа «добавлено кеширование +20%», «оптимизированы запросы к базе +60%». В итоге если заказчик на второй день спросит как дела, менеджер с централизованной системой скажет — уже стало на 80% лучше, можете взять текущий билд проверить, а мы продолжаем работать. Менеджер децентрализованной может ответить только «хз, ща пойду спрошу, показать пока нечего».
                                                                        • +1
                                                                          Извините, но я все равно Вас не понимаю. Вы говорите, что централизация заставит сотрудников заливать код раз в день и чаще на центральный сервер? Нет, не заставит. Всегда найдутся люди, которые копят ченжи и выкладывают по завершении таска — это вопрос баланса между комфортом программиста и требованиями решаемой задачи. Если Вам нужны итеративные улучшения, если есть возможность этот итеративный прогресс подтверждать тестами, то просто попросите человека выкладывать почаще — и не важно, какая при этом у вас используется система, это не вопрос техпроцесса совершенно.
                                                              • 0
                                                                Могу сказать за крупные канадские телекомуникационные компании — все поголовно юзают ClearCase (а «обломки» Нортела юзают нортеловские костыли над clearcase под названием NEU)
                                                              • 0
                                                                Скажите, а как в такому случае владельцами коммитов управлять?
                                                                Вот допустим, я в свой реп код кладу как Вася, и мой друг Вася тоже с таким же именем. Как нам потом разобраться, кто что коммитил?
                                                                • +1
                                                                  git config user.name «Vasya Ivanov»
                                                                  git config user.email «vasyaivanov@ivanovs.com»

                                                                  Не работает, если вы полные тезки с одним email-адресом на двоих
                                                                  • 0
                                                                    А конфиги то где? Каждый сам себе админ получается?
                                                                    • 0
                                                                      Если доступ к главному репозиторию через ssh, то вы можете отличать пользователей по публичным ключам.
                                                                      • 0
                                                                        А без ssh эту проблему не решить?
                                                                        • 0
                                                                          Доступ к удаленному git репозиторию выполняется тремя способами:
                                                                          1) По HTTP. В основном используется для read-only доступа. Push делать можно, но это не удобно. В этом случае можете различать пользователей по имени/паролю или любым другим удобным способом для HTTP-авторизации;
                                                                          2) Собственный протокол git:// — только read-only;
                                                                          3) ssh — в 99% случаев используется для read-write доступа, идентификацировать пользователей можно по имени/паролю или публичному ключу.
                                                                          • +1
                                                                            Топором. Отрубать пальцы тем, кто ставит одинаковые имена пользователей и почту.
                                                                            Встречный вопрос, а как вообще идентифицируются пользователи в SVN (давно это было, не помню).
                                                                            • 0
                                                                              Когда создаёшь реп, в конфиге эту инфу указываешь.

                                                                              Дело не в одинаковых именах и почтах, а в том, что пользователь сам это может настраивать, и администратор не может это контролировать.
                                                                              • 0
                                                                                Когда речь идет о центральном сервере (svn, или git/hg+shh) — тут можно что-то контролировать, а когда такого сервера нет — то невозможно. Само понятие децентрализованности предполагает отсутствие такого центрального контролирующего админа.
                                                                                • 0
                                                                                  Да, спасибо.
                                                                                  Для меня вот собственно, это и является основным сдерживающим фактором, для перехода на git/hg.
                                                                                  • 0
                                                                                    Но я так и не понял проблемы… Проблема в том, что пользователь может назначить себе любое имя? Или в чем? Отказываться из-за этого от всех прелестей git/hg как-то глупо что ли…
                                                                                    • –1
                                                                                      В том числи и в этом.
                                                                                      А что за прелести git/hg такие?
                                                                                      • 0
                                                                                        Ой, перечитайте уже комменты, лень в сотый раз писать…
                                                                                        • –1
                                                                                          Тогда почитайте и мои, где я писал, что прелести такие не нужны, а добавляют только хлопот.
                                                                                          • 0
                                                                                            Заметил особенность. Из-за отсутствия какиз-либо преимуществ svn над git/hg пользователи первой стараются изо всех сил доказать, что им и так хорошо, а все преимущества последних — совсем не преимущества =) Такие смешные, ей богу =)
                                                                                            • –2
                                                                                              Преимущества ваши смешные, ей богу ;)
                                                                                              Не всем они нужны, а менять репозиторий ради того, что может никогда не потребоваться, зачем?
                                                                                    • +1
                                                                                      Делается «центральный» репозиторий, и на нем настраиваются права кто что где может делать, если пользователь поставил левое имя, ему просто не получится что-то сделать… Например в mercurial есть расширение acl для этого, про git не знаю, не пользовался…
                                                                                      • 0
                                                                                        Спасибо, посмотрим, как будет время.
                                                                                        Но, что тогда остаётся от фишек hg/git? Ведь в случае с центральным репом получается, тот же svn нет?
                                                                                        • 0
                                                                                          Нет. Все git остается git`ом. Просто левый человек не сможет сломать центральный реп. Остальная польза от децентрализованности к вашим услугам.
                                                                                        • 0
                                                                                          Вопрос вот в чем. Центральный сервер лишь ограничит число тех, кто на нем сможет изменять историю.
                                                                                          А как вычислить того, кто что-то нехорошее закоммитил и при этом представился, как Вася Пупкин с несуществующим ящиком?
                                                                                          • 0
                                                                                            Выше писали про плагин acl, который позволяет отличать пользователей по публичным ключам.
                                                                                            Но тогда другой вопрос, если система децентрализованная, ведь злоумышленник может любому валидному пользователю закомитить в его реп код от имени кого угодно, а валидный пользователь сможет его уже в реп положить.
                                                                                            • 0
                                                                                              Извините, эта уже какая-то совсем надуманная проблема. Кто вас заставляет шарить локальные репозитории дальше личного компьютера? Такими темпами мы дойдем до того, что гит небезапасасен, потому что злоумышленник может с компьютера валидного пользователя коммитить пока тот покурить вышел
                                                                                              • 0
                                                                                                Ага, вырубив его при этом топором по голове.
                                                                                                Мне как администратора хранилища кода, важно видеть ответственного за каждую строчку кода, вот я и пытаюсь понять, как контролировать процесс коммитов в центральный реп.
                                                                                                • 0
                                                                                                  Вам уже говорили, есть ssh-ключи, есть различные методы авторизации.
                                                                                                  Дело в том что git-репозиторий, в отличие от svn — это не какой-либо серверный процесс, это просто директория на диске с определенной структурой. Если у злоумышленника нет доступа к этой директории коммитить он туда не сможет. Так что проблема «злоумышленник может любому валидному пользователю закомитить в его реп код от имени кого угодно» довольно таки сомнительная. А для центрального репозитория вам несколько решений уже показали
                                                                                              • 0
                                                                                                Для этого используется система контроля доступа к общему репозиторию. Например Gerrit это может делать. Пользователь побавляет свое имя и публичный ключ на сервер и когда следующий раз коммитишь — Gerrit проверяет что твой ключ валиден.
                                                                                    • 0
                                                                                      У SVN есть свои собственные учетки.
                                                                          • 0
                                                                            А часто 'коннект' лежит?
                                                                          • +2
                                                                            Ветки в subversion абсолютно неюзабельные из-за тупого механизма merge. В пше проблем с этим практически не было. Правда пше значительно сложнее в освоении. Все эти rebase, stash изрядно разрывают мозг.
                                                                            • +2
                                                                              Это актуально для версии 1.5. Начиная с 1.6 механизм merge починили, и для большинства сценариев он не отличается от такового для git.
                                                                              • 0
                                                                                Недавно, после почти года «гитования» был вынужден вернуться на SVN и увидел разительную разницу в качестве merge. Так что может в 1.6 и улучшили merge, но он все равно не тянет.
                                                                              • 0
                                                                                Активно пользуюсь гитом уже 1.5-2 года (с использованием нескольких веток): rebase не юзал. И кстати, младшего программера-линускоида знающего svn заставил использовать git — он уже через 2-3 дня стабильно с ним работал.
                                                                                • +1
                                                                                  Зря не юзал rebase. Он полезен, когда работаешь с веткой, но при этом в master что-то поменялось. Чтобы не делать git merge master в свою ветку можно просто сделать git rebase master — все изменения из мастера перейдут в свою ветку и при этом она так и останется веткой.
                                                                              • 0
                                                                                Для меня, например, решающим фактором при переходе на Меркуриал стала скорость работы и удобная gui-оболочка.
                                                                              • 0
                                                                                Ниже есть разбивка по регионам, странный какой то тренд у Tурции — кто то знает почему так???
                                                                              • 0
                                                                                Посмотрел. Вижу, что гугл следит за ботинками blogs.timeslive.co.za/soccer/2010/02/25/another-mercurial-boot-from-nike/
                                                                                • +1
                                                                                  В вашем графике шкалят запросы с турции, где как выясняется git=ходить. :)
                                                                                • 0
                                                                                  Есть такая штука — git-svn. Создаешь git-репозиторий на основе svn-репа (он автоматом добавляется как удаленный) и работаешь. И сам счастлив, и команда дальше копошится в этом своем svn. Я так некоторое время работал — впечатления отличные.
                                                                                  • 0
                                                                                    А то, что там необходим «git-svn rebase», проблемы не вызывает ли?
                                                                                    • 0
                                                                                      Да, это менее удобно, чем работать с удаленным git-репом. Но более удобно, чем работать без git вообще.
                                                                                      • +1
                                                                                        а в чем проблема то с svn rebase?
                                                                                  • +5
                                                                                    Пробовали.
                                                                                    Только вопрос зачем на него переходить, если нас устраивает svn, остался нерешённым.
                                                                                    • +5
                                                                                      Можно хотя-бы попробовать и сравнить. Там чудовищная разница в скорости работы. После гита работать на свне — пытка.
                                                                                      • +2
                                                                                        Пробовал меркуриал, и немного гит.
                                                                                        А в чём скорость то выражается?
                                                                                        • 0
                                                                                          В апдейтах/коммитах например. Ну и то что в гите ты в основном работаешь с локальным репозиторием. Любая операция там происходит со скоростью клика.
                                                                                          • 0
                                                                                            Ну вот, скорость пофиксали. Дальше то что?
                                                                                            • 0
                                                                                              Читайте комменнты ниже. А лучше — обзоры в сети. А ещё лучше — попробуйте.
                                                                                          • 0
                                                                                            Ну и с бранчами на гите работать проще и быстрее. Свн бранчи не поощряет, там с ними связываться страшно.
                                                                                        • 0
                                                                                          Вы ветки используете? Один не докомитил и вся команда ждет? Или один забажил — другие также ждут фикса? Вот для этого git — все изолированно. Ну и редактирование текста комита — не радость ли? :)
                                                                                          • +3
                                                                                            в svn тоже можно редактировать комментарии к коммиту :)
                                                                                            • +1
                                                                                              Что значит изолированно?
                                                                                              У нас принято коммитить в бренч, в транк код попадает только когда проверен.
                                                                                              Текст коммита в svn тоже можно изменять.
                                                                                              • 0
                                                                                                А раз принято коммитить в бранч, то все же получше попробуйте гит. Работа с бранчами там очень и очень удобнее.
                                                                                          • +5
                                                                                            Все всё пробовали. Только всегда всё в конечном итоге сводится к тому, что всё равно есть некий центральный репозиторий, куда все пушат свои изменения. Поэтому децентрализованность выливается по сути только в то, что есть возможность локально коммитить и откатываться, если что-то поломал.

                                                                                            Про прочие удовольствия (сейчас я говорю только про гит) вообще молчу. Гитовские сабмодули — тихий ужас по сравнению с svn externals. Все превозносимые фичи по работе с ветками (типа «как что-то понадобилось, сделал git branch и правишь изменения уже в новой ветке!») разом пропадают, если у нас есть build-каталог внутри дерева.
                                                                                            • +1
                                                                                              Поясните последнюю фразу, пожалуйста. Почему бы build-каталог не заигнорить?
                                                                                              • –1
                                                                                                Потому что, например, при работе с CMake, имя билд-каталога может быть произвольным. Кто-то собирает в build, кто-то в Build, а debian вообще будет собирать в obj-i686-linux-gnu/obj-amd64-linux-gnu/...(всего 270 возможных вариантов). Всё не наигноришь.
                                                                                                • 0
                                                                                                  Подождите, почему бы не использовать out-of-source билд и имя каталога привязывать например к бранчу, как-нибудь так?
                                                                                                  То есть /build/<branch_name> — папка для сборки бранча?..
                                                                                                  • 0
                                                                                                    Потому что при сборке пакета, если не писать полностью самому правила сборки (что есть неправильно), debhelper сам решает, в каком именно каталоге собирать. И поскольку структура файловой системы заранее неизвестна, сборка ВСЕГДА идёт не ниже корня пакета. Так что единственным способом является создавать для всего структуру типа:
                                                                                                    ~/workspace/ — каталог с проектами
                                                                                                    ~/workspace/projectname/ — «проект»
                                                                                                    ~/workspace/projectname/projectname-scm/ — настоящая папка с исходниками из гита

                                                                                                    Это не так удобно, и опять-таки, не позволит хранить каталог debian/ с инструкциями для сборки в SCM, только в ~/workspace/projectname/. Это не есть удобно.
                                                                                              • 0
                                                                                                а можно подробнее про тихий ужас?

                                                                                                свн:
                                                                                                1. прописываем субрепу без ревизии. при каждом обновлении основной репы получаем обновления и субреп. внезапно и не вовремя.
                                                                                                2. прописываем субрепу с ревизией. чтобы обновить субрепы нужно узнать номер последней ревизии, изменить проперти основной репы и обновиться. много телодвижений.

                                                                                                гит:
                                                                                                основная репа и субрепы обновляются независимо. простыми движениями мы можем в любой момент:
                                                                                                1. обновить вообще всё
                                                                                                2. обновить только основную репу
                                                                                                3. обновить субрепы
                                                                                                4. обновить конкретные субрепы.
                                                                                                • 0
                                                                                                  свн.1. Чтобы обновить без сабреп, достаточно использовать svn up --ignore-externals.
                                                                                                  свн.2. Чтобы обновить экстернал, заходим в каталог с экстерналом, делаем svn up, заодно узнаём новую ревизию, много телодвижений.

                                                                                                  гит.1. Я просто запишу это «простое» телодвижение:
                                                                                                  alias.up = "!git pull origin master;git submodule foreach --recursive 'git pull origin master'"

                                                                                                  Когда я работаю с корпоративным проектом, который использует пачку внутренних библиотек, я не хочу отслеживать состояние сторонних библиотек и самолично их апдейтить. Я подключаю транк, где должна лежать последняя рабочая версия, и всегда работаю с кодом со всеми исправлениями. Именно для этого подключается экстернал без указания ревизии. А в гите такой возможности технически нет, кроме как вышеупомянутыми макросовыми костылями. Точно так же придётся писать костыль, чтобы зачекаутить проект, проинициализировать сабмодули и потом их обновить с помощью вышеозначенного макроса. Одной командой это, разумеется, сделать нельзя.

                                                                                                  Плюс интересное возникает при попытке сделать сабмодуль частью репозитория. Казалось бы, в чём проблема вмержить просто всю историю сабмодуля в родительскую, подправив пути. Но нет, при мерже репозиториев кутима мы попробовали ВСЕ способы, которые нашли в интернете, и в лучшем случае получали потерю половины истории.
                                                                                                  • 0
                                                                                                    свн1. а толку? любой чистый чекаут притянет последние версии субмодулей.

                                                                                                    свн2. ага, потом копируем ревизию, идём в родительский каталог, читаем пропертю svn:externals, вставляем в нужное место скопированную ревизию, прописываем пропертю обратно. очень весело.

                                                                                                    угу, должна, вот только там не только «последние исправления», но и «последние баги» и «последние изменения в апи» и вовсе не факт, что все эти последние изменения должны войти в ту версию продукта, которую ты сейчас разрабатываешь.
                                                                                                    • 0
                                                                                                      свн1. Свежий чекаут вообще всегда притягивает последнюю версию. И в свне, и в гите, и даже во всяких дарксах. Почему бы сабмодулям без указания ревизии надо вести себя по-другому?

                                                                                                      свн2. Если это так сложно, воспользуйтесь гуёвыми утилитами. И, да, их в свн, точно так же, как и в гите, можно просто отредактировать в файлике. Только svn, в отличие от гита и его .gitmodules/.gitignore, складывает свою информацию в .svn/, а не срёт ей в корне репозитория.

                                                                                                      Последние баги в транк попадать не должны. Если баги есть в стабильной версии в транке, это узнаётся всегда постфактум, конкретная используемая версия тут не причём. Ну а неожиданно менять в библиотеке апи, без сохранения обратной совместимости, в т.ч. бинарной… ну я даже не знаю, такое только в опенсорсе бывает, и то у школьников. Повторюсь, хотите жесткой привязки к конкретной ревизии — в свне эта возможность есть. А в гите обратной возможности нет.
                                                                                                      • 0
                                                                                                        свн1. потому что гит хранит не только ссылку на субрепу, но и сами исходники из неё. именно поэтому после коммита в субрепу надо сделать коммит в суперрепу, чтобы изменения отразились и на ней.

                                                                                                        свн2. что за гуёвые утилиты? в гите мне не приходится ничего дополнительно редактировать после каждого апдейта субмодулей. и вопрос не в том какая система контроля версий лучше, а какой подход лучше. разумеется специальными скриптиками можно сделать работу с свн как в гите и с гитом как в свн-е. в данном случае подход свн-а вида «либо полная недетерминированность версии, либо кропотливое ручное изменение версий» никуда не годится по сравнению с гитовским «обновляемся по требованию»

                                                                                                        ога, сферический транк в вакууме всегда стабилен х) а с чего ты взял, что неожиданно? вполне ожидаемо. библиотека развивается и поддерживать 100500 интерфейсов никому не нужно.
                                                                                                        • 0
                                                                                                          свн1. Гит не хранит исходники из сабрепы, даже каталог под неё (да, это тоже замечательная особенность гита — нельзя сохранить структуру каталогов). После чекаута надо делать git submodule update --init.
                                                                                                          Впрочем, не понимаю, какое отношение это имеет к вопросу. git clone, bzr branch, darcs get, svn co — все они всегда выкачивают последнюю версию репозитория. Спрашивается, почему поведение сабмодуля, не привязанного к ревизии, должно при чекауте должно быть иным?

                                                                                                          свн2. Тот же TortoiseSVN или просто любимые IDE. К счастью, в отличие от гита, который имеет исключительно набор бинарников (что вынуждает все веб-обёртки и аналогичные утилиты делать system(...) и парсить вывод), в свне есть библиотеки и можно работу с правкой любых свойств сделать сколь угодно удобной и кропотливо что-то править нигде не нужно. Если же говорить о подходе, то подход «обновляем по требованию» не лучше подхода «либо последняя версия, либо обновляем по требованию».

                                                                                                          В школьной лаборатной или студии из полутора человек, возможно, библиотеки и «развиваются» подобным образом. В более-менее серьёзном софте — нет. Qt несколько лет поддерживала классы от Qt3, майкрософт десяток лет минимум поддерживал ansi-версии функций от winapi (если не поддерживает до сих пор). И так в общем-то делают все нормальные люди.
                                                                                                          • 0
                                                                                                            свн1. точно. я ж не использую сабмодули ^^' я просто создаю субрепозитории, но не прописываю их как субмодули. в этом случае в суперрепе хранятся строго определённые версии и субреп.

                                                                                                            свн2. в данном случае гуёвые утилиты только добавляют сложности. эмм, про tortoisegit не слышал?

                                                                                                            так делают те, у кого много ресурсов. обычный софт разрабатывается без поддержки мегатонн легаси кода. так что хватит пальцы гнуть.
                                                                                            • 0
                                                                                              Мы тоже пользуемся SVN'ом. И хотя может быть и рады перейти на HG, но без нормальной поддержки Unicode'а на Windows пользоваться им невозможно. Не нравятся мне лично разные непонятно кем написанные fixutf8 плагины, которые того и гляди перестанут работать в следующей версии HG. А с GIT на Windows так еще хуже.
                                                                                              На данный момент SVN удобнее всего в плане совместимости для работы на Windows (VS, Eclipse, и еще туча IDE) + Mac OS (XCode).
                                                                                              • 0
                                                                                                А что за проблемы с юникодом у меркуриала в windows?
                                                                                                • 0
                                                                                                  Из коробки невозможно засунуть файлы с юникодовым именем ("ファイル.txt" например) в репозиторий.
                                                                                            • +11
                                                                                              Им еще очень много кто пользуется, и будет пользоваться.