Subperversion

[kika]

Почитал http://users.livejournal.com/_winnie/407870.html и вдруг осознал что никогда в жизни не использовал svn. Было несколько раз когда просто чекаутил из чьего-то публичного репозитория и на этом всё (то есть буквально - ничего кроме svn co не использовал

Comments

[anatolix]

Живо в Яндексе и Facebook-е только потому что может тянуть на пару порядков большие репозитории чем git/hg. Ну в смысле если у тебя размер репозитария несколько сотен гигов, то git требует это иметь на каждой машине и тормозит ужасно. Вообщем мы мечтаем svn закрасить пока не можем, кроме него либо perforce весьма платный либо свою систему контроля версий писать как google

[alll]

это хорошо ещё если как гугл
а то выйдет ещё как майкрософт

[anatolix]

А что у ms что-то кроме perforce сейчас?

[alll]

Принимать в зачот только сиюсекндное положение дел довольно опрометчиво. История многому учит. Например был такой в высшей степени замечательный продукт, как SourceSafe.

недоделки какие-то все

[freedom_of_sea]

кроме того, слишком много внимания этому уделяют

[rblaze]

На darcs можешь посмотреть, его продают как совершенно отличающийся, но за первые 15 минут я так и не врубился.

[dottedmag]

Даркс случился в ту же вспышку.

[evolver]

Не совсем строго по теме вороса, но я вот тоже не очень понял весь хайп вокруг "намного более простого мерджа в git" против "намного более сложного мерджа в svn". По мне так разница могла бы быть, если бы у одного из инструментов был бы умный мерджер, понимающий стукруту соединямых файлов, а не просто рассматривающий их как plain text files.

Может я что важное упустил?

[anatolix]

у git как минимум если ты возьмешь один файл и его разрежешь на 2 части оно это поймет, у svn _возможно_ есть внешние тулзы которые могут это одуплить, но они платные - см araxis merge, хотя точно не уверен.

[stepbeyond]

я тоже долго не мог понять hype svn merge vs hg merge. я довольно хорошо знаю svn, чтобы понять что масса критики относится к svn pre-1.6? когда с мержами было плохо. Сейчас паттерн branch-merge_from_trunk_nerge_from_trunk...-reintegrate_merge работает хорошо. но только если ему следуют и регулярно вмерживают транк в бранч. при этом два параллельных бранча могут обмениваться изменениями только в полуручном режиме cherry-pickingом. mercurial (как и git) даёт возможность продолжать вести свою ветку после reintegrate merge (там просто нет такого режима, поскольку бранчи не маппируются в другой путь дерева). В результате появляются возможность вести совершенно другой workflow, не завязанный на единственный trunk, нет вопросов "что делать с бранчем после вмерживания в транк, как его откатить, какпродолжить его развивать независимо?". То есть преимущества касаются не столько единичного мержа, сколько увеличения возможностей ведения большого количества довольно простых workflow против svn

[evolver]

Кстати, забавно, что первые четыре хита в гугле на "bad merge" - это 4 ссылки на stackoverflow и проблемы с Hg. И это при том, что я никогда особо Mercurial не интересовался. Симптоматично?

[kika]

у старого hg был очень тупой merge