Количество переключений бранчей при этом такое, что svn тупо сдох бы

Просто создай несколько рабочих каталогов. И получится переключение еще быстрее чем в git :p

Я, кстати, так и делаю. У меня в репозитории кроме самого проекта лежит еще тулза-парсер для конвертации старого формата файла в новый. Если мне нужно подкорректировать формат файла (а данных там много), я выгружаю тулзу, корректирую ее, коммичу. Результирующий файл переношу в проект и работаю над ним дальше.

Миф развенчан

В общем, когда говорят о «лучшем объединении в git», то:
1) Имеют ввиду subversion до 1.5; с этой версии он отслеживает историю ветвлений и слияний;
2) Имеют ввиду subversion до 1.5 (опять); с этой версии появилось интерактивное разрешение конфликтов;
3) Путают софт и подходы по работе с ним, в данном случае CVS-подход («все толпятся в одном транке, коммитятся как можно чаще, апдейтятся еще чаще») и DCVS-подход («выделение веток каждому разработчику/группе разработчиков»). Subversion может и так, и так; если вы выбрали первый путь, и это создало вам проблемы, это только ваша проблема, а не проблема Subversion. ИМХО, хорошо и то и то, но каждое для своих случаев.

Чего здесь нет (но ожидалось), так это процедура корректного (безопасного) вливания ветки в транк, которая состоит из двух merge: первый для синхронизации (и проверки), второй - для собственно интеграции (с ключем --reintegrate). Все-таки редко кто читает ман.

Также, в номинации «Золотой комментарий» победил tailgunner: Приведите реальный пример когда git/mercurial объеденит лучше, чем subversion (комментарий)

Всем спасибо! Надеюсь было интересно не только мне.

Просто создай несколько рабочих каталогов. И получится переключение еще быстрее чем в git :p

Ну вот у меня такая ситуация. Бранчей около двадцати. Причем последовательность мерджей нелинейная. С svn это сделать просто невозможно. Кстати, субъективно, git конфликты таки лучше разруливает чем убогий subversion. Особенно если это переименования/перемещения файлов.

Бранчей около двадцати

Но зачем?

Бранчей около двадцати. Причем последовательность мерджей нелинейная. С svn это сделать просто невозможно.

Запросто. Два способа:
Способ 1. Выгружай только бранч и работай с ним, коммить сколько хочешь. Абсолютно независимо от транков и других бранчей.
Способ 2. Хочешь выгружать весь репозиторий - выгружай, а работай только с бранчем, коммить. Опять-таки на другое не повлияет.

Кстати, субъективно, git конфликты таки лучше разруливает чем убогий subversion.

Смотри здесь, п. 1 и п. 2. Так что субъективно, объективно - нет.

Особенно если это переименования/перемещения файлов.

А git умеет отслеживать перемещение/переименование, если это сделано не средствами git, а, например, Midnight Commander.

По поводу мерджей - в svn мердж модифицирует дерево и по нему в общем случае невозможно восстановить ветки, подвергшиеся слиянию. В git и hg мердж - это специальный коммит, который можно отменить. Мердж создает нелинейную историю в git и hg. в svn такое невозможно.

Вот и вся разница. На самом деле мигрировать с cvs и svn нужно только тогда, когда возникла необходимость. Обычно это связано с удобставми git и hg по работе с историей, если этой самой истории уделяется внимание, и определен процесс коммита (обычно под git и hg проще реализовать минимальные коммиты - потому как серию для коммита можно создать на основе своего помоечного рабочего бранча, и потом провести хитрый финт с заменой истории рабочего бранча, что все вместе делает очень удобным последующий просмотр истории, которая без бардака, со всеми понятными коммитами). Если вам это все не надо, гранулярность коммита большая (типа коммитим сразу готовую версию, и тп., политике коммитов не уделяется много внимания, то вам мигрировать с cvs/svn крайне нежелательно - процесс работы усложнится, а вы ничего не получите взамен. Вот если вы вдруг обнаружили, что 75% разрабов вашего проекта использует для работы с репозиторием git-svn, git-cvs, или что там еще бывает для hg - тогда стоит подумать о миграции.

Ну и вообще, если есть сомнения в целесообразности - не нужно мигрировать. Даже на форумах об этом спрашивать не нужно. Если возникла какая-то суровая проблема с svn - можно спросить, решит ли ее git или hg. Но с вашими запросами - вам это все не нужно.

Придумал, когда git объеденит лучше - когда в финальных состояниях деревьев конфликта нет, а в середине могут быть конфликты между патчами. git и hg не линеаризуют историю. Если потом сказать rebase для линеаризации - все развалится :) svn не умеет нелинейную историю.

Но многим как раз нравится, что в svn все линейно, и все можно разложить по коммитам, и они все последовательно наложатся.

Способ 1. Выгружай только бранч и работай с ним

Все двадцать? Спасибо, я пешком постою.

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

Честно говоря, я просто не понимаю, как в 21 веке можно пользоваться svn.

Смотри здесь, п. 1 и п. 2. Так что субъективно, объективно - нет.

И опять - это все не то. Даже банальный rebase и потом reintegration в svn убог и чреват конфликтами на совершенно ровном месте (например add/add он до сих пор не умеет автоматически разруливать, потому что тупой).

А git умеет отслеживать перемещение/переименование, если это сделано не средствами git, а, например, Midnight Commander.

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

Кстати да, поскольку по работе вынужден пользоваться svn, то уже давно все мерджи делаю в git-svn клоне, да и бранчами в svn уже почти никто не пользуется. Общий svn стал тупо trunk-ом, и вся разработка идет в локальных git-ах. Если в какой-то момент svn просто исчезнет, никто этого, скорее всего, и не заметит.

Все двадцать? Спасибо, я пешком постою.

В subversion - одна команда. Сложно?
Вопрос: как это сделать в git?

нельзя использовать бранчи собственно по назначению, так что единственный способ - клонировать весь репозиторий

Не понял. Ты можешь клонировать хоть весь проект, от отдельный каталог, хоть отдельный файл. Как хочешь. В Subversion.

например add/add

Здесь поподробней, плиз. Что значит add/add?

git даже умеет отслеживать, если значительная часть содержимого файла была перенесена в другой

Погуглил. Да, прикольно.

Придумал, когда git объеденит лучше - когда в финальных состояниях деревьев конфликта нет, а в середине могут быть конфликты между патчами

Попробую на досуге.

По поводу мерджей - в svn мердж модифицирует дерево и по нему в общем случае невозможно восстановить ветки, подвергшиеся слиянию. В git и hg мердж - это специальный коммит, который можно отменить. Мердж создает нелинейную историю в git и hg. в svn такое невозможно.

Наверное вы опять говорите про старый Subversion. Новый (1.7) остлеживает все ветвления и слияния (вы это имели ввиду под нелинейностью?). Также, если ветка удалена, ее всегда можно восстановить. Вот вырезка из официального мануала:

Now that your private branch is merged to trunk, you may wish to remove it from the repository.
...
But wait! Isn't the history of that branch valuable? What if somebody wants to audit the evolution of your feature someday and look at all of your branch changes? No need to worry. Remember that even though your branch is no longer visible in the /branches directory, its existence is still an immutable part of the repository's history. A simple svn log command on the /branches URL will show the entire history of your branch. Your branch can even be resurrected at some point, should you desire (see the section called “Resurrecting Deleted Items”).

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

Нет. В общем, моё заявление про то, что hg прост и понятен для всех, включая продавцов мороженого, снимается.

Это абсолютно нелогичное поведение. Как оно вообще может трогать мои активные незакомиченные данные, даже если может их пропатчить? Если файл не закоммичен - значит он в процессе обработки. Оно должно потребовать коммита. Иначе, как я откачу на этот файл правку, если моя правка верна, а чужая - абсолютно неверна? А оно мне взяло, и без предупреждения всё исправило. Оно однозначно должно потребовать коммита, и без него не мержить ничего вживую. Иначе, как мне вообще восстановить мою One Two Tri? Я только придумал рифму к One, а update мне его заменил без спросу.

Впрочем, и достоинство именно в том, что можно сначала закоммитить, и только потом принимать/посылать. В svn нужно каждый раз слать свои изменение в главный сервер, нарываясь на конфликт. Или, действительно, у каждого свой независимый репозиторий. Что далеко не всегда эффективно, и иногда может выбираться именно потому, что в svn по-другому нельзя, чем потому что это более удобный способ. hg/git универсальнее, подходят от 1 до 1048576 человек, и от 1 до 35000 веток.

Но теперь мне понятно, что и hg не так прост, как кажется. Зато он копирует поведение текущего svn, что кому-то может понравиться. :)

В subversion - одна команда. Сложно?

Да, сложно держать 20 чекаутов, тогда как достаточно было бы одного.

Вопрос: как это сделать в git?

git checkout branch1; git merge branch0; git checkout branch2; git merge branch1; ...

И все это выполняется с огромной скоростью, тогда как у svn даже примитивнейшие операции занимают туеву хучу времени. Даже банальный diff между двумя бранчами заставляет svn уйти в глухую задумчивость, тогда как git это делает моментально.

Ты можешь клонировать хоть весь проект, от отдельный каталог, хоть отдельный файл. Как хочешь. В Subversion.

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

Здесь поподробней, плиз. Что значит add/add?

Один и тот же файл добавлен в двух бранчах, которые мы сливаем. git это разрулит молча, svn поднимет истерику.

Как оно вообще может трогать мои активные незакомиченные данные

Ты сказал так сделать - hg делает.

Если файл не закоммичен - значит он в процессе обработки. Оно должно потребовать коммита.

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

А если в рабочем каталоге какое-то серьезное незаконченное изменение - просто не делай pull -u.

Но теперь мне понятно, что и hg не так прост, как кажется. Зато он копирует поведение текущего svn

Нет. SVN не дает тебе _сделать коммит_, если есть параллельные модификации на сервере.

Ты сказал так сделать - hg делает.

Проще, когда не нужно задумываться о таких неоднозначностях.

Нет. Если ты делаешь hg up на «грязной» рабочей копии - значит, ты хочешь проверить, как эта грязь работает на другой ревизии.

Да, это удобно. Во всех случаях, кроме вышеприведённого, когда я просто забыл сделать commit. :)

Чего здесь нет (но ожидалось), так это процедура корректного (безопасного) вливания ветки в транк, которая состоит из двух merge: первый для синхронизации (и проверки), второй - для собственно интеграции (с ключем --reintegrate). Все-таки редко кто читает ман.

«молодець, хвалю!» (С)

:)

Способ 1. Выгружай только бранч и работай с ним

Все двадцать? Спасибо, я пешком постою.

почитайте о svn switch

По поводу мерджей - в svn мердж модифицирует дерево и по нему в общем случае невозможно восстановить ветки, подвергшиеся слиянию

4.2 man reverse merge

Да, сложно держать 20 чекаутов, тогда как достаточно было бы одного.

В Subversion для данного случая - один! Ты, похоже, что-то себе нафантазировал про Subversion.

у svn даже примитивнейшие операции занимают туеву хучу времени

Фантазии. Пруф или не было.

Я говорю про «мета-бранчи», роль которых в git могут исполнять отдельные полные клоны.

Отличие мета-бранчей от просто бранчей?

git это разрулит молча, svn поднимет истерику.

Если предок у двух файлов - один - subversion разрулит. А если это именно бранч, то предок должен быть один.

Пока что из того, что ты говорил, только отслеживание переименований можно записать в плюсы git. Все остальное subversion умеет. Ты либо использовал старый svn либо использовал его неправильно.

у svn даже примитивнейшие операции занимают туеву хучу времени

Фантазии. Пруф или не было.

это ужасная (для вас) правда. погуглите

почитайте о svn switch

Нет уж, спасибо. Минуты вместо долей секунды, для операции, которая выполняется много раз в день? Идите вы все в сраку с вашим древним тормозным говном мамонта!

В Subversion для данного случая - один! Ты, похоже, что-то себе нафантазировал про Subversion.

svn co намного дешевле по времени, чем svn switch, так что гуляй мимо.

Фантазии. Пруф или не было.

git checkout - доли секунды. svn switch - минуты и до хера траффика.

git clone - доли секунды. svn checkout - десятки секунд.

Отличие мета-бранчей от просто бранчей?

Это «бранч», содержащий текущее состояние группы бранчей.

Если предок у двух файлов - один - subversion разрулит. А если это именно бранч, то предок должен быть один.

Какой такой «предок»? Их отдельно добавили в двух разных бранчах. И там и там патч приложили.

Все остальное subversion умеет.

Так и cvs «все умеет». Просто твой убогий subversion «все умеет» медленно, глупо и через жопу.

:)

я указал просто что есть возможность не выгружать все и иметь все в тоже время. длительность сего процесса вопрос №2. здесь нужно сказать что сам свн медленный, но это понемножку решают в AF.

есть конторы которым нужны возможности свн (в основном acl, центральный репо), и им плевать на остальное

ps пользователь свн'а, гита и немного ртути

Ага, и в таких конторах как правило svn давно уже деградировал до чисто формально поддерживаемого trunk-а, а вся реальная работа идет через git-svn.