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