Subperversion
Oct. 17th, 2013 12:09 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
kikaПочитал http://users.livejournal.com/_winnie/407870.html и вдруг осознал что никогда в жизни не использовал svn. Было несколько раз когда просто чекаутил из чьего-то публичного репозитория и на этом всё (то есть буквально - ничего кроме svn co не использовал).
Как-то сразу с cvs переехал на hg, а потом на git, но гит я как-то еще не освоил.
Кстати, а если ли чего-нибудь интересненькое? Как-то вот была вспышка - Hg, bzr, darcs, потом git - и всё, конец истории.
Как-то сразу с cvs переехал на hg, а потом на git, но гит я как-то еще не освоил.
Кстати, а если ли чего-нибудь интересненькое? Как-то вот была вспышка - Hg, bzr, darcs, потом git - и всё, конец истории.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-10-18 06:35 pm (UTC)По отзывам clear case непередаваемое неработающее гавно, как почти все продукты rational.
no subject
Date: 2013-10-18 06:53 pm (UTC)Глюки в p4 не то чтобы смертельны, по крайней мере, данные он не теряет. В нашем случае он (точнее его прокси) ложился по SEGV при выкачке больших объемов данных. Я бы больше волновался за то, что пользователи вас проклянут: клиентский интерфейс там ОЧЕНЬ своеобразный (хотя есть и хорошие вещи, вроде time-lapse view).
Про clearcase -- ну, возможно, у них была та самая dev team про которую пишут выше.
Кстати, а что вы такого кладете в svn на несколько сотен гиг? У нас есть один такой репозиторий, но он ровно один и даже до одной сотни по-моему еще не дотянул, хотя в него лет десять валят всякое говно. Собственно, я к чему: даже если git не держит репы на полтерабайта, необходимость эти полтерабайта держать именно под одной историей version control'а как правило -- антипаттерн (наш случай не исключение). В гите можно же в принципе креативно порезать это все с помощью submodules/subtree на более мелкие части.
no subject
Date: 2013-10-21 04:51 pm (UTC)У нас сейчас дамп репозитария со всеми версиями 1.3Tb, это сырой без diff-ов, для конвертации репозитария, т.е. на самом деле если его хранить как git должно быть сильно меньше, наверное раз в 20. Весь код всего поиска за 15 лет существования компании, в данный момент в сумме 1.2 миллиона коммитов. Но там не весь наш код все чужое, что мы используем с нашими патчали лежит там же включая исходники gcc и которым мы собираемся. Но вообщим git такое уже не тянет. Но мне кажется у ребят типа facebook и google должно быть сильно побольше, да и нам надо на будущее задумываться.
no subject
Date: 2013-10-21 06:36 pm (UTC)no subject
Date: 2013-10-21 09:18 pm (UTC)p.s. при экспоненциальном росте все, что ты написал за всю жизнь примерно столько же сколько ты напишешь за следующий год, так что как минимум не помогает, а вообще изначальное утверждение тоже высосано из пальца, есть успешные продукты сильно старше.
no subject
Date: 2013-10-21 09:53 pm (UTC)no subject
Date: 2013-10-21 09:58 pm (UTC)Я согласен что можно проблему вдвое облегчить этим. Ну и еще разделить на несколько репозиториев то, что ты совместно не изменяешь типа contrib - еще в двое. Но это тебя спасет ну допустим в 4 раза - проблему это никак не решает, максимум откладывает на 2 года, или облегчает чуть-чуть.
no subject
Date: 2013-10-24 09:54 am (UTC)Для contrib'а в принципе такая модель подходит, для всего остального уже не очень.
no subject
Date: 2013-10-24 11:02 am (UTC)no subject
Date: 2013-10-24 02:01 pm (UTC)no subject
Date: 2013-10-24 04:23 pm (UTC)Из этих несколько гб часть написана людьми, часть это чужой код, типа libxml, и еще часть наверное генереная(у нас не все генеренное туда коммитится большую часть часть проще каждый раз генерить). Ну т.е. если у тебя 1000 человек в течении 200(без выходных)*15 дней, каждый в день пишет по 1Кб кода (это 25 стро кода) и поделить это пополам т.к. людей было не всегда 1000, то это 1.5Gb исходников.
no subject
Date: 2013-10-24 11:18 am (UTC)У меня есть альтернативная теория, которая выглядит так: у БОЛЬШИХ компаний, есть БОЛЬШИЕ проекты. Т.е. грубо говоря вот наш поиск это БОЛЬШОЙ проект, а не много маленьких проектиков.
Ее можно исскуственно распилить на части, в несколько репозитариев, и некоторые люди будут считать это configuration management но это не оно. Configuration management это что-то что делает всем жизнь удобней, а не то что из-за приколов системы хранения в git требует по другому описывать архитектуру проекта.
Ну т.е. типичное разбиение это все порезать и заморозить интерфейсы, но есть реально много изменений которые удобно делать синхронно. Например если ты поменяешь формат индекса неплохо было бы чтобы это случилось сразу в роботе и поиске, когда ты меняешь всю кодировку в своих KKm кода на unicode это тоже глобальное изменение, и далать это в 100 маленьких проектах невозможно. В 100 мелких проектах тебе приходится из проекта в проект copy/paste кусочки кода вместо того, чтобы обращаться с кодом правильно.
Но чем еще характерны большие компании, это тем что у них много ресурсов и они могут специально для себя заточить всю инфраструктуру, поэтому скоро FB заточит по слухам Mercurial, google уже заточил что-то свое. Мы вот думаем затачивать или FB подождать.
no subject
Date: 2013-10-24 03:43 pm (UTC)Момент второй: делать синхронные изменения в тучу мест разом -- это тоже не configuration management :-) Это, возможно, удобно если вы деплоите методом svn export на чистую машину, но это не всегда применимо. В любом другом workflow помимо собственно коммита потребуется что-нибудь еще: скрипты миграции, изменение формата паковки, еще дочерта всего...
no subject
Date: 2013-10-24 04:20 pm (UTC)no subject
Date: 2013-10-24 04:37 pm (UTC)no subject
Date: 2013-10-24 04:46 pm (UTC)no subject
Date: 2013-10-24 04:56 pm (UTC)Но я, допустим, верю что у вас там все очень монолитно (кстати, как вы тогда обеспечиваете согласованность задеплоенного в разные места вашей инфраструктуры тогда?). Вопрос в другом: почему даже те конторы, у которых архитектура задумывалась изначально компонентной, все равно предпочитают валить все в одну кучу?
no subject
Date: 2013-10-24 05:09 pm (UTC)Компонент это такая штука которая ты утверждаешь, что будет изменяться и собираться по отдельности. Обычно таких штук много, но есть тенденция что иногда архитектуру надо менять всю, т.е. например рефакторить разбиение на компоненты, или менять что-то между компонентами и т.п.
Вот тут "компонентный" подход часто сосет т.к. выясняется что эти компоненты заморожены, и переразбивать их нельзя.
Вопрос собственно в чем - с чем прощще мириться отстутсвием git или затруднением круных рефакторингов системы, ну мы вот так сделали выбор в чем проблема. Починят git или mercurial - переедем.
no subject
Date: 2013-10-24 06:11 pm (UTC)Например. Но это игра в одни ворота -- я-то не знаю вашей специфики :-)
> Компонент это такая штука которая ты утверждаешь, что будет изменяться и собираться по отдельности
Скорее, штука, высокоуровневым интерфейсом для которой являются фичи. Для примера, у нас есть компонент, который поддерживает отдельная команда и который потом просто линкуется в общий бинарник. Это отдельный компонент, отдельная папочка в перфорсе со своим стейджингом, ну и так далее. Есть и пример обратного: "папочка в перфорсе" в которой лежат три взаимосвязанные программы для разных, скажем так, runtime environment.
> затруднением круных рефакторингов системы
Какбэ я всегда считал, что рефакторинг с нарушением границ компонентов называется реинжинирингом. Или, проще говоря, взять и написать заново :-) Но я в общем-то ни к чему не призываю, даже к внедрению гита :-)
no subject
Date: 2013-10-24 07:39 pm (UTC)Ты про наши фичи или про вообще? У нас можно фичей считать одну программу, проблема в том что у фичей есть что-то общее, а именно интерфейс, бывает явный бывает не явный.
Взять и заново написать - я почти не знаю проекты исключая мелких с которыми это получается. Медленно менять в нужную сторону можно.
no subject
Date: 2013-10-25 04:44 pm (UTC)Я про фичи в широком смысле, как результат декомпозиции. Вот у нас есть набор требований, им более-менее удовлетворяет система состоящая из таких-то частей, умеющих то-то и то-то. Вот эти "умения" -- они собственно и определяют "лицо" компонента: если они другие, то это уже другой компонент.
no subject
Date: 2013-10-25 04:54 pm (UTC)Была кодировка csYandex которая в 8 бит влезала русский, старорусский, английский и все романо-германские языки. Лет 5 назад появилась поддержка всякого странного типа арабского и турецкого и пришлось перейти.
Перейти технически ничего сложного, просто нужно было заменить строки по всей программе с живими 200 человеками которые не прекращали ее писать. Сделал это один человек.
no subject
Date: 2014-08-12 07:56 am (UTC)no subject
Date: 2014-08-12 10:04 am (UTC)no subject
Date: 2013-10-24 10:10 am (UTC)Краткое содержание: FB попытались потестировать git scalability на 15Gb repo, 4M коммитов и 1M файлов и в общем пришли к такому же выводу -- не тянет.
С другой стороны, в linux.git пока всего 1Gb и 0.5M коммитов -- пока вроде не жмет.
PS. Не хочу никого обидеть, но похоже что (анти)паттерн "свалить все в кучу не думая о CM'е" достаточно общий для больших контор. В P4 эту фишку, кажется, просекли и специально точили продукт под нее -- почему его так и любят.