Вот помню у меня на проекте git отжигал, а svn сливал, правда проектов у меня не было.

дело не в том, как они ветки объединяют, а насколько удобно с множеством веток работать. в dvcs это удобно, а в svn/cvs/perforce это гимор.

У git-а больше примочек для работы с ветками. Например, когда кто-то делает коммитит в trunk, некоторые изменения могут поступить в какую-то branch. SVN так не умеет.

В принципе, я не спорю если какими-то костылями в SVN можно-таки сделать подобное, но ведь в git есть очень удобный инструментарий для подобных задач.

У svn вообще есть ветки? Раньше создавалась папки с сырцами. Типа trunk итп. Т.е. исключительно ручная работа была (если я правильно понял мануал).

Из одной статьи «Subversion does not have special commands for branching or tagging» :)

некоторые изменения могут поступить в какую-то branch

cherry picking?

Да. Ветки есть. У нас была ветка на разработчика, иногда задачу. В git просто удобней.

cherry picking?

Да, удобная штука.

А в svn разве есть вообще какая-то нормальная мержилка? Пойду проверю...

А в svn разве есть вообще какая-то нормальная мержилка?

Да, довольно-таки адекватная.

Да проще простого: вот есть фича, которую держали в отдельной ветке или даже на компе одного из разработчиков. Соответственно нужно залить несколько коммитов, хотя в репозиторий, в свою очередь, успел получить несколько коммитов. Лучшее что может сделать svn - слить оба набора коммитов в один, потеряв последовательность изменений.

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

Да, есть. Но всё равно, в git/hg лучше и понятнее. :)

Гит не может решить лишь одновременное изменение в одинаковых строках

так и свн так же

насколько удобно с множеством веток работать

Пример?

Например, когда кто-то делает коммитит в trunk, некоторые изменения могут поступить в какую-то branch

Это уже ближе, но все равно хотелось бы видеть пример?

Да, довольно-таки адекватная.

Когда я сделал svn update, она смержила в изменённые мною исходники прямо поверх, не спросив. Обидно. :) Хотя, полагаю, это поведение можно изменить. Но тот же hg по умолчанию сначала делает новую ветку, на всякий случай, а потом уже мержь, если хочешь. Ну или мержь автоматом, но потом всё равно будет видно, где что произошло.

У svn вообще есть ветки?

Еще и как.

Из одной статьи «Subversion does not have special commands for branching or tagging» :)

Ты наверное чилал про subversion 1.0?

Тем не менее, отлично помню, как свн не умел решать конфликты вообще - он просто оставлял оба файла и ещё третий выходной файл.

Я только что проверил - может. Хотя мне тоже так казалось.

Гит не может решить лишь одновременное изменение в одинаковых строках, а в случае оного не мусорит в фс, как некоторые бокланоцвски.

И что делает git в случае изменений в одинаковых строках?

Cherry-picking - это когда мерджится какой-то конкретный коммит, а не все изменения до текущей версии, так? Subversion это умеет - ключ -c при merge.

это и был пример.

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

Ты наверное чилал про subversion 1.0?

возможно

я предвижу, что тебе этого мало

Да, ты прав.

лучше 1 раз увидеть, чем 100 раз услышать

Да, но я хотел бы знать куда смотреть.

Чтобы действительно понять, нужно не пару дней, а один проект там провести, это немаленькая задачка, на это пока времени пока нет. Однажды обязательно попробую, а пока я использую (и изучаю) svn и не хочу бросать это дело на полпути: разобраться в одной системе лучше, чем недоразобраться в двух. Тем более что замечаний к нему (svn) у меня сейчас нет. Но тема о возможных преимуществах интересует, поэтому и задаю этот вопрос.

лучше всего разбираться в обеих системах. тогда и вопросов не возникнет, что лучше/хуже, в разных ситуациях. если у тебя нет замечаний к svn — ты слишком мало им пользовался. можешь посмотреть видео-презентацию автора git в гугле, он достаточно доходчиво объясняет. http://www.youtube.com/watch?v=4XpnKHJAok8

git/hg просто лучше во всём. «это нэвозможно понят, дэти. это нужно просто запомнит». :) После освоения их, это будет понятно со всей очевидностью. Если есть навыки svn, то лучше - hg, а то в git сразу встретите несколько неоднозначностей, которые только запутают.

Вот заметки для мигранта svn -> hg, с личным опытом:

http://m.habrahabr.ru/post/108443/

Если есть навыки svn, то лучше - hg, а то в git сразу встретите несколько неоднозначностей, которые только запутают.

вранье. я осваивал git после опыта cvs,svn,perforce,vss — никаких проблем и неоднозначностей не возникло.

зы: ошибся, опыта perforce у меня тогда еще не было. наоборот, после гита осваивал perforce на работе, вспомнил как матерился (и до сих пор матерюсь)

Вы - это вообще не показатель. Технарщина, то есть технология ради технологии, желание разбираться в скучных вещах - для таких любые сложности только вызов, новый уровень в квесте (кто-то любит хардкорные задачи, когда больше сопротивления, кто-то - когда всё просто). :)

А неоднозначностей хватает, они все известны. Начиная от необходимости add на изменённый файл. Чтобы пользоваться git - нужно знать, как он работает. Чтобы пользоваться hg - нужно представлять, как она работает. hg проще.

Поэтому, если стоит вопрос, что брать, но не хватает знания и понимания - лучше брать hg. Если хватает - то такой вопрос обычно не стоит.

Уже нет!

http://m.habrahabr.ru/post/108443/

Команда, использующая Subversion, часто днями или неделями ничего не добавляет в репозиторий. В таких командах новички боятся залить что-то в репозиторий из-за опасения поломать билд

Это проблема не subversion, а такого подхода к контролю версий, когда не делаются ветки. В subversion можно замечательно делать ветки и этой проблемы не будет.
P. S. Золотой комментарий.

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

С версии 1.5 subversion тоже об этом знает.
Вообще-то у subversion есть 2 ванианта слияния - обычный и reintegrate. Вы может объединять либо изменение с начала создания ветки(да-да svn об этом знает) - diff3, или «втупую» сравнивать две ветки - как хотите.

Subversion, по сути, система контроля изменений для файлов, а в Mercurial контроль изменений применяется ко всему каталогу, включая все подкаталоги.

Не проверял. Но считаю это скорее достоинством.

Теперь часть, где вы просто должны поверить мне на слово. Mercurial лучше, чем Subversion.

Привык верить только фактам.

А такая надежда была на эту статью...

Я говорю, я может быть, не знаю или не помню, как там в svn, но я изменил один файл у юзера1, закоммитил, изменил второй файл у юзера2, сделал update, и мне на живую внеслось это изменение, безо всяких ветках.

В hg вообще такое невозможно, потому что там «коммит всему центр», сначала закоммить или откати своё, а потом уже разбирай прилетевшие обновления. В svn такого фиксированного коммита нет вообще, коммит сразу мчится в репозиторий куда-то сливаться.

Фишка в том, что в svn, если я правильно понял вашу модель использования, получается просто у каждого свой репозиторий, отдельный, который он ведёт вручную. чтобы не было именно вот таких ситуаций. В hg же подобное делается автоматически, и для того, чтобы не смешать коды - не нужно суетиться. Именно благодаря разделению коммита и смешивания - это две операции, разные. Хотя я не всё понял в вашем подходе и его эффективности, по мне - так это вообще неудобно (но сильно зависит от специфики проекта, сколько людей лезут в одно и то же).

И, кстати, вообще индивидуальные независимые репозитории, которые потом как-то сливаются, вести проще (а как сделать это удобно в svn, я вообще не представляю).

Не проверял. Но считаю это скорее достоинством.

:) Там же далее это объяснено. По файлам НЕВОЗМОЖНО определить наборы изменений. Прочитайте, там этот момент в картинках описан. Почему это недостаток, серьёзный недостаток.

Привык верить только фактам.

Если верить только фактам, то сначала придётся поверить вообще тому, что является фактом, и поверить некоему набору аксиом. И даже после этого можно пропустить много полезного. :) Факт вообще штука слишком размытая...

Впрочем, я не пытаюсь вас убедить в использовании git/hg вместо svn. Хотя она и лучше. Но доказывать это я не буду, это как доказывать, что буква «ю» звучит как «ю». :)

Лучшее что может сделать svn - слить оба набора коммитов в один

4.2

Вот и выходит, что свн с черепашкой - говно, а без черепашки - говно редкостное.

сколько вы проработали с svn? а что может черепашка что не может кли?

Кто-то может привести реальный пример, когда git (или mercurial) объединит две ветки лучше, чем svn?

Нерелевантно. Сила DVCS не в том, что у них лучший merge, а в том, что они позволяют вещи, которых в CVCS просто нет. Например, работу с mq (в Mercurial), работу без обращения к серверу, редактирование истории.

В hg вообще такое невозможно, потому что там «коммит всему центр», сначала закоммить или откати своё, а потом уже разбирай прилетевшие обновления.

Можно конкретнее? А то у меня подозрение, что ты просто плохо знаешь hg.

Можно конкретнее? А то у меня подозрение, что ты просто плохо знаешь hg.

Я же написал - я сделал изменение одним пользователям, закоммитил, сделал изменение другим пользователем, но не закоммитил в центральный репозиторий, а сделал update. Оно просто смержилось, и всё, и поминай, как звали.

В hg бы, независимо от того, сделал бы я pull (-u) или fetch, оно бы так просто не прошло. Я бы не смог сделать мерж, не закоммитив - это раз. Мерж бы отразился в истории отдельным событием - это два.

А если Legit использовать, то вообще хорошо.

В hg бы, независимо от того, сделал бы я pull (-u) или fetch, оно бы так просто не прошло.

Сейчас специально попробовал: сделал клон до tip-3, измененил файл, и hg pull -u молча обновил рабочую копию до tip (как и должен был).

Сейчас специально попробовал: сделал клон до tip-3, измененил файл, и hg pull -u молча обновил рабочую копию до tip (как и должен был).

pull -u вообще не мержит. Мы говорим про получение изменения в файл, который был уже изменён.

pull -u вообще не мержит

Смотря что называть «мержит». У него внутри 3-way merge, но merge changeset не создается.

Мы говорим про получение изменения в файл, который был уже изменён.

Да, именно об этом.

$ hg pull -u
pulling from XXX
searching for changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 57 changes to 57 files
merging lib/YYY
56 files updated, 1 files merged, 48 files removed, 0 files unresolved

Какая у тебя версия hg?

2.3

Уже почти утро, и я наивно думал поспать. Ну да ладно, попробую объяснить, пока разум чуть поспит без меня. :)

Объясняю на пальцах:

Есть Вася. Есть Петя. Есть некий центральный репозиторий (чтобы избежать путаницы, что почём).

есть файл:

One
Two
Three

Вася в этом файле меняет One на Odin. Коммитит в ц/р.

Петя в этот момент, в файле One Two Three меняет Three на Tri.

Делается update.

Что мы получаем в случае SVN:

файл Odin Two Tri. При этом! Мы можем вернуться к варианту One Two Three, мы можем вернуться к варианту Odin Two Three, но мы, если я правильно понял(!), не можем вернуться к варианту, который у нас только что был на руках - Odin Two Tri. Это в SVN. Что будет в hg - я сейчас сам лично проверю.

Хм. Я сделал pull -u, и у меня произошло то же самое. Странно, но я постоянно использовал один и тот же файл с двух компьютеров, и мне предлагало закомиттить перед тем, как мержить. Что-то я уже сам запутался. Приношу свои извинения.

Теперь и у меня появились претензии к mercurial. Но разбираться с ними буду завтра.

Вот так, спокойно жил и спокойно спал, чего меня потянуло на эксперименты...

Вот помню у меня на проекте git отжигал, а svn сливал, правда проектов у меня не было.
у меня на проекте
правда проектов у меня не было.

5 баллов, че.

Теперь и у меня появились претензии к mercurial.

Кхм. Ну, поспишь - изложи %) По-моему, логичное поведение.

Ну вот, например, типичный способ применения DVCS: есть trunk, он постоянно меняется. И есть кучка локальных feature branch-ей, из которых собирается пропатченная версия. Процесс обновления до trunk выглядит как цепочка merge из trunk и локальных бранчей. Количество переключений бранчей при этом такое, что svn тупо сдох бы, а в git это все занимает секунды даже для проекта размером с llvm.

Ну вот, например, типичный способ применения DVCS: есть trunk, он постоянно меняется. И есть кучка локальных feature branch-ей, из которых собирается пропатченная версия. Процесс обновления до trunk выглядит как цепочка merge из trunk и локальных бранчей. Количество переключений бранчей при этом такое, что svn тупо сдох бы, а в git это все занимает секунды даже для проекта размером с llvm.

Эталонный blub-эффект же.

Нерелевантно. Сила DVCS не в том, что у них лучший merge, а в том, что они позволяют вещи, которых в CVCS просто нет. Например, работу с mq (в Mercurial), работу без обращения к серверу, редактирование истории.

Да, пожалуй это самое правильное утверждение.
Данным топиком просто хотел (для себя) развенчать миф о «более лучшем слиянии веток». Ну, или подтвердить, в таком случае знать эффект; привык понимать о чем говорю.

P. S. Почитал про mq; интересно.