kika: (default)
[personal profile] kika
Почитал http://users.livejournal.com/_winnie/407870.html и вдруг осознал что никогда в жизни не использовал svn. Было несколько раз когда просто чекаутил из чьего-то публичного репозитория и на этом всё (то есть буквально - ничего кроме svn co не использовал).
Как-то сразу с cvs переехал на hg, а потом на git, но гит я как-то еще не освоил.

Кстати, а если ли чего-нибудь интересненькое? Как-то вот была вспышка - Hg, bzr, darcs, потом git - и всё, конец истории.

Date: 2013-10-17 07:28 pm (UTC)
From: [identity profile] anatolix.livejournal.com
Живо в Яндексе и Facebook-е только потому что может тянуть на пару порядков большие репозитории чем git/hg. Ну в смысле если у тебя размер репозитария несколько сотен гигов, то git требует это иметь на каждой машине и тормозит ужасно. Вообщем мы мечтаем svn закрасить пока не можем, кроме него либо perforce весьма платный либо свою систему контроля версий писать как google

Date: 2013-10-17 08:07 pm (UTC)
From: [personal profile] alll
это хорошо ещё если как гугл
а то выйдет ещё как майкрософт

Date: 2013-10-17 08:59 pm (UTC)
From: [identity profile] anatolix.livejournal.com
А что у ms что-то кроме perforce сейчас?

Date: 2013-10-17 10:13 pm (UTC)
From: [personal profile] alll
Принимать в зачот только сиюсекндное положение дел довольно опрометчиво. История многому учит. Например был такой в высшей степени замечательный продукт, как SourceSafe.

Date: 2013-10-18 07:38 am (UTC)
From: [identity profile] anatolix.livejournal.com
SourceSafe помоему в ms не применялся никогда и возможно это даже не продукт, а просто кто-то постебался так :)

Date: 2013-10-17 11:22 pm (UTC)
From: [identity profile] 0242.livejournal.com
во многих тимах в майкрософте TFS уже многие годы

Date: 2013-10-18 07:35 am (UTC)
From: [identity profile] anatolix.livejournal.com
А под ним на сколько большие репозитарии?

Date: 2013-10-18 07:08 pm (UTC)
From: [identity profile] 0242.livejournal.com
Не особенно большие. Я бы сказал -- максимум команды до ста человек. Все, что больше, обычно в Source Depot (aka Perforce).

Date: 2013-10-28 06:06 pm (UTC)
From: [identity profile] 0242.livejournal.com
Не особенно большие. Я бы сказал -- максимум команды до ста человек. Все, что больше, обычно в Source Depot (aka Perforce).

Date: 2013-10-18 11:10 am (UTC)
From: [personal profile] ex0_planet
Perforce, кроме того что платный, еще и говно. Ну то есть он, конечно, работает, и даже хорошо вписывается в около-корпоративное окружение (контроль доступа там, локальные кэши), но вот это вот все временами неприятно подглюкивает: то файл забудет вычекнуть, то сервер на ровном месте упадет, то еще что-нибудь.... Ну и с пользовательской стороны там тоже bondage & domination.

К P4 есть еще примочка для превращения его в распределенную систему (p4 sandbox) и какая-то тулза для интеграции с Git'ом (p4 fusion), но я их пока порассматривать не успел.

По отзывам коллег еще неплох ClearCase, но он тоже весьма небесплатен.

Date: 2013-10-18 01:10 pm (UTC)
From: [identity profile] vvs2002.livejournal.com
К ClearCase'у требуется дедикэйтед CC dev team.

Date: 2013-10-18 06:56 pm (UTC)
From: [personal profile] ex0_planet
К git'у для использования в абстрактной "корпорации", боюсь, потребуется не меньшая....

Date: 2013-10-18 06:35 pm (UTC)
From: [identity profile] anatolix.livejournal.com
Google p4 вроде в свой скрипт заворачивал и было ничего, мы на него сейчас смотрим, думаем. Про подглюкивание спасибо скажу человеку.

По отзывам clear case непередаваемое неработающее гавно, как почти все продукты rational.

Date: 2013-10-18 06:53 pm (UTC)
From: [personal profile] ex0_planet
А что за скрипт? Сходу не гуглится....

Глюки в p4 не то чтобы смертельны, по крайней мере, данные он не теряет. В нашем случае он (точнее его прокси) ложился по SEGV при выкачке больших объемов данных. Я бы больше волновался за то, что пользователи вас проклянут: клиентский интерфейс там ОЧЕНЬ своеобразный (хотя есть и хорошие вещи, вроде time-lapse view).

Про clearcase -- ну, возможно, у них была та самая dev team про которую пишут выше.

Кстати, а что вы такого кладете в svn на несколько сотен гиг? У нас есть один такой репозиторий, но он ровно один и даже до одной сотни по-моему еще не дотянул, хотя в него лет десять валят всякое говно. Собственно, я к чему: даже если git не держит репы на полтерабайта, необходимость эти полтерабайта держать именно под одной историей version control'а как правило -- антипаттерн (наш случай не исключение). В гите можно же в принципе креативно порезать это все с помощью submodules/subtree на более мелкие части.

Date: 2013-10-21 04:51 pm (UTC)
From: [identity profile] anatolix.livejournal.com
Мне лень искать, было какое-то видео про управления версиями в гугле где человек рассказывал как они пытаются отказаться от перфорса с помощью его обертывания и замены, но на момент рассказа там был и perforce и скрипт в который его обернули.

У нас сейчас дамп репозитария со всеми версиями 1.3Tb, это сырой без diff-ов, для конвертации репозитария, т.е. на самом деле если его хранить как git должно быть сильно меньше, наверное раз в 20. Весь код всего поиска за 15 лет существования компании, в данный момент в сумме 1.2 миллиона коммитов. Но там не весь наш код все чужое, что мы используем с нашими патчали лежит там же включая исходники gcc и которым мы собираемся. Но вообщим git такое уже не тянет. Но мне кажется у ребят типа facebook и google должно быть сильно побольше, да и нам надо на будущее задумываться.

Date: 2013-10-21 06:36 pm (UTC)
From: [identity profile] evolver.livejournal.com
За 15 лет надо продукт EOL-ить и начинать новый!

Date: 2013-10-21 09:18 pm (UTC)
From: [identity profile] anatolix.livejournal.com
Спасибо за ваше ценное мнение (c) kukutz

p.s. при экспоненциальном росте все, что ты написал за всю жизнь примерно столько же сколько ты напишешь за следующий год, так что как минимум не помогает, а вообще изначальное утверждение тоже высосано из пальца, есть успешные продукты сильно старше.

Date: 2013-10-21 09:53 pm (UTC)
From: [identity profile] evolver.livejournal.com
Да я не пытаюсь ничей чужой use case решить. Если бы я начал упираться в такие проблемы, то наврено взял бы какой-нибудь baseline и все, что ниже услал бы в архив, а то, что выше продолжило бы жить в репо.

Date: 2013-10-21 09:58 pm (UTC)
From: [identity profile] anatolix.livejournal.com
ну вот проблема в том что у тебя в repo будет каждый раз больше чем ты усылал в архив все предыдущие годы.
Я согласен что можно проблему вдвое облегчить этим. Ну и еще разделить на несколько репозиториев то, что ты совместно не изменяешь типа contrib - еще в двое. Но это тебя спасет ну допустим в 4 раза - проблему это никак не решает, максимум откладывает на 2 года, или облегчает чуть-чуть.

Date: 2013-10-24 09:54 am (UTC)
From: [personal profile] ex0_planet
Если есть Очень Быстрая Сеть, то в гите можно, в принципе, пореференсить все локальные копии на публично доступный сетевой ресурс. После этого в клонах на машинах разработчиков останутся только их локальные изменения (околонулевые по размеру) и место будет расходоваться только на чекаут.

Для contrib'а в принципе такая модель подходит, для всего остального уже не очень.

Date: 2013-10-24 11:02 am (UTC)
From: [identity profile] anatolix.livejournal.com
Ну для этого нужно очень сильно хотеть именно git. Ну и очень быстрой сети у нас нету, 75% людей на ноутах по wifi работает, а кто-то вообще дома по VPN.

Date: 2013-10-24 02:01 pm (UTC)
From: [identity profile] evolver.livejournal.com
Может быть я лезу туда, куда не стоит, но неужели у вас десятки гигабайт сорцов, написанных людьми? Или же это всякая мультимедия, данные для тест-кейсов, machine-generated code, etc?

Date: 2013-10-24 04:23 pm (UTC)
From: [identity profile] anatolix.livejournal.com
Ну вот сейчас померял чистое дерево, которое счекаутил достатчно давно - 3.8G получилось. Десятки это я имел ввиду репозитарий(вместе с .svn у меня сейчас 7.5G, а у git наверное будет 40), а вообще речь шла про большие компании не только нас, у них может и 400 быть.

Из этих несколько гб часть написана людьми, часть это чужой код, типа libxml, и еще часть наверное генереная(у нас не все генеренное туда коммитится большую часть часть проще каждый раз генерить). Ну т.е. если у тебя 1000 человек в течении 200(без выходных)*15 дней, каждый в день пишет по 1Кб кода (это 25 стро кода) и поделить это пополам т.к. людей было не всегда 1000, то это 1.5Gb исходников.

Date: 2013-10-24 11:18 am (UTC)
From: [identity profile] anatolix.livejournal.com
Твой соседний коммент почему-то стал "Spammed comment" тут его не видно хотя в почте он есть.

У меня есть альтернативная теория, которая выглядит так: у БОЛЬШИХ компаний, есть БОЛЬШИЕ проекты. Т.е. грубо говоря вот наш поиск это БОЛЬШОЙ проект, а не много маленьких проектиков.

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

Ну т.е. типичное разбиение это все порезать и заморозить интерфейсы, но есть реально много изменений которые удобно делать синхронно. Например если ты поменяешь формат индекса неплохо было бы чтобы это случилось сразу в роботе и поиске, когда ты меняешь всю кодировку в своих KKm кода на unicode это тоже глобальное изменение, и далать это в 100 маленьких проектах невозможно. В 100 мелких проектах тебе приходится из проекта в проект copy/paste кусочки кода вместо того, чтобы обращаться с кодом правильно.

Но чем еще характерны большие компании, это тем что у них много ресурсов и они могут специально для себя заточить всю инфраструктуру, поэтому скоро FB заточит по слухам Mercurial, google уже заточил что-то свое. Мы вот думаем затачивать или FB подождать.

Date: 2013-10-24 03:43 pm (UTC)
From: [personal profile] ex0_planet
Момент первый: проект != репозитарий, я призываю скорее к репозитарию на компонент. Интерфейсы морозить никто не предлагает.

Момент второй: делать синхронные изменения в тучу мест разом -- это тоже не configuration management :-) Это, возможно, удобно если вы деплоите методом svn export на чистую машину, но это не всегда применимо. В любом другом workflow помимо собственно коммита потребуется что-нибудь еще: скрипты миграции, изменение формата паковки, еще дочерта всего...

Date: 2013-10-24 04:20 pm (UTC)
From: [identity profile] anatolix.livejournal.com
Ну подожди - вот допустим ты изменил формат индекса, изменив формат структуры, написав код которые его формирует(он где-то в роботе будет работать) и который использует(это где-то в поиске в ражировании). Что именно предлагается сделать 2 или 3 коммита, которые будут по разному проходить review и есть шанс что один из них откатят, а второй забудут или сделать один коммит?

Date: 2013-10-24 04:37 pm (UTC)
From: [personal profile] ex0_planet
А если на робота задеплоят старую версию, а в ранжирование новую?

Date: 2013-10-24 04:46 pm (UTC)
From: [identity profile] anatolix.livejournal.com
Деплой это уже отдельное тестирование, такая провека есть, но ты знаешь же что чем позже находишь баг тем дороже это получается, поэтому лучше чтобы работоспособность кода у девелперов не зависила от тестов на deploy которые возможно будут через месяц-два после коммита

Date: 2013-10-24 04:56 pm (UTC)
From: [personal profile] ex0_planet
Ну, смотри, ты мне сейчас фактически говоришь, что разрезать поиск формату индекса нельзя. Дык ё, не режь его там!

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

Date: 2013-10-24 05:09 pm (UTC)
From: [identity profile] anatolix.livejournal.com
Я как раз сказал что разрезать поиск по программам нельзя, можно конечно все что работает с индексом отрезать в одну штуку.

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

Вот тут "компонентный" подход часто сосет т.к. выясняется что эти компоненты заморожены, и переразбивать их нельзя.

Вопрос собственно в чем - с чем прощще мириться отстутсвием git или затруднением круных рефакторингов системы, ну мы вот так сделали выбор в чем проблема. Починят git или mercurial - переедем.

Date: 2013-10-24 06:11 pm (UTC)
From: [personal profile] ex0_planet
> все что работает с индексом отрезать в одну штуку
Например. Но это игра в одни ворота -- я-то не знаю вашей специфики :-)


> Компонент это такая штука которая ты утверждаешь, что будет изменяться и собираться по отдельности
Скорее, штука, высокоуровневым интерфейсом для которой являются фичи. Для примера, у нас есть компонент, который поддерживает отдельная команда и который потом просто линкуется в общий бинарник. Это отдельный компонент, отдельная папочка в перфорсе со своим стейджингом, ну и так далее. Есть и пример обратного: "папочка в перфорсе" в которой лежат три взаимосвязанные программы для разных, скажем так, runtime environment.


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

Date: 2013-10-24 07:39 pm (UTC)
From: [identity profile] anatolix.livejournal.com
Да нет никакой специфики. Просто когда мы сейчас пишем код мы так же не знаем где его потом будем изменять, так что это все теоретизация. Есть только набор примеров вида " 5 лет назад заменили все строки на уникод во всем коде "

Ты про наши фичи или про вообще? У нас можно фичей считать одну программу, проблема в том что у фичей есть что-то общее, а именно интерфейс, бывает явный бывает не явный.

Взять и заново написать - я почти не знаю проекты исключая мелких с которыми это получается. Медленно менять в нужную сторону можно.

Date: 2013-10-25 04:44 pm (UTC)
From: [personal profile] ex0_planet
О, а с юникодом-то в чем засада? Потом, всегда ж можно писать "масштабируемо", хотя и ценой некоторого оверхеда -- у вас-то какие с этим проблемы?

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

Date: 2013-10-25 04:54 pm (UTC)
From: [identity profile] anatolix.livejournal.com
Сейчас ни в чем, просто когда начинали писать unicode еще не изобрели.

Была кодировка csYandex которая в 8 бит влезала русский, старорусский, английский и все романо-германские языки. Лет 5 назад появилась поддержка всякого странного типа арабского и турецкого и пришлось перейти.

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

Date: 2014-08-12 07:56 am (UTC)
From: [personal profile] ex0_planet
Прошло N времени, фейсбук таки заточил mercurial, в связи с чем хочется поинтересоваться: смотрели? прижилось оно в яндексе?

Date: 2014-08-12 10:04 am (UTC)
From: [identity profile] anatolix.livejournal.com
Мы на него вяло смотрим, скрипт конверсии сломался на большом файле(там квадратичный diff), времени это поправить пока ни у кого не нашлось, найдется чуть позже.

Date: 2013-10-24 10:10 am (UTC)
From: [personal profile] ex0_planet
Тут неожиданно нагуглилось вот такое: http://comments.gmane.org/gmane.comp.version-control.git/189776

Краткое содержание: FB попытались потестировать git scalability на 15Gb repo, 4M коммитов и 1M файлов и в общем пришли к такому же выводу -- не тянет.

С другой стороны, в linux.git пока всего 1Gb и 0.5M коммитов -- пока вроде не жмет.

PS. Не хочу никого обидеть, но похоже что (анти)паттерн "свалить все в кучу не думая о CM'е" достаточно общий для больших контор. В P4 эту фишку, кажется, просекли и специально точили продукт под нее -- почему его так и любят.

Date: 2013-11-08 09:26 am (UTC)
From: [identity profile] panchul.livejournal.com
ClearCase феноменальное феерическое гавно, perforce осваиваю и он мне не нравится, svn - идеал для меня.

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

Date: 2013-10-17 07:50 pm (UTC)
From: [identity profile] freedom_of_sea.livejournal.com
кроме того, слишком много внимания этому уделяют

Date: 2013-10-18 06:04 am (UTC)
From: [identity profile] rblaze.livejournal.com
На darcs можешь посмотреть, его продают как совершенно отличающийся, но за первые 15 минут я так и не врубился.

Date: 2013-10-18 09:34 am (UTC)
From: [identity profile] dottedmag.livejournal.com
Даркс случился в ту же вспышку.

Date: 2013-10-18 09:37 am (UTC)
From: [identity profile] dottedmag.livejournal.com
Вспышка была из-за того, что все кинулись делать DVCS. Сделали, двое выжили, активность спала.

Новых идей особо нет, разве что fossil пытается issue tracking сделать распределенным, с коммитами и слияниями.

P.S: хорошо бы кто-нибудь придумал что-то новое, а то UI победителя настолько неконсистентен, что про него аж коаны пишут в насмешку (http://stevelosh.com/blog/2013/04/git-koans/).

Date: 2013-10-18 02:00 pm (UTC)
From: [identity profile] evolver.livejournal.com
Не совсем строго по теме вороса, но я вот тоже не очень понял весь хайп вокруг "намного более простого мерджа в git" против "намного более сложного мерджа в svn". По мне так разница могла бы быть, если бы у одного из инструментов был бы умный мерджер, понимающий стукруту соединямых файлов, а не просто рассматривающий их как plain text files.

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

Date: 2013-10-21 09:33 pm (UTC)
From: [identity profile] anatolix.livejournal.com
у git как минимум если ты возьмешь один файл и его разрежешь на 2 части оно это поймет, у svn _возможно_ есть внешние тулзы которые могут это одуплить, но они платные - см araxis merge, хотя точно не уверен.

Date: 2014-11-13 07:29 pm (UTC)
From: [identity profile] stepbeyond.livejournal.com
я тоже долго не мог понять 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.
при этом cherry-picking делается несколько хуже. Точнее в svnе он естественнее.

Date: 2013-10-18 04:51 pm (UTC)
From: [identity profile] aplsms.livejournal.com
У нас SVN в полный рост, но многие репозитории миррорятся в git.

Из нового был анаос jet brains о том что они делают собственную систему контроля версий. С большой игровой зоной и девушками легкого поведения.

Date: 2013-10-21 09:58 pm (UTC)
From: [identity profile] evolver.livejournal.com
Кстати, забавно, что первые четыре хита в гугле на "bad merge" - это 4 ссылки на stackoverflow и проблемы с Hg. И это при том, что я никогда особо Mercurial не интересовался. Симптоматично?

Date: 2013-11-11 11:57 pm (UTC)
From: [identity profile] kika.livejournal.com
у старого hg был очень тупой merge

Profile

kika: (Default)
kika

January 2017

S M T W T F S
1234567
89 1011121314
151617181920 21
22232425262728
293031    

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 21st, 2017 12:24 pm
Powered by Dreamwidth Studios