Subperversion

[kika]

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

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

Comments

[ex0_planet]

Если есть Очень Быстрая Сеть, то в гите можно, в принципе, пореференсить все локальные копии на публично доступный сетевой ресурс. После этого в клонах на машинах разработчиков останутся только их локальные изменения (околонулевые по размеру) и место будет расходоваться только на чекаут.

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

[anatolix.livejournal.com]

Ну для этого нужно очень сильно хотеть именно git. Ну и очень быстрой сети у нас нету, 75% людей на ноутах по wifi работает, а кто-то вообще дома по VPN.

[evolver.livejournal.com]

Может быть я лезу туда, куда не стоит, но неужели у вас десятки гигабайт сорцов, написанных людьми? Или же это всякая мультимедия, данные для тест-кейсов, machine-generated code, etc?

[anatolix.livejournal.com]

Ну вот сейчас померял чистое дерево, которое счекаутил достатчно давно - 3.8G получилось. Десятки это я имел ввиду репозитарий(вместе с .svn у меня сейчас 7.5G, а у git наверное будет 40), а вообще речь шла про большие компании не только нас, у них может и 400 быть.

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

[anatolix.livejournal.com]

Твой соседний коммент почему-то стал "Spammed comment" тут его не видно хотя в почте он есть.

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

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

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

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

[ex0_planet]

Момент первый: проект != репозитарий, я призываю скорее к репозитарию на компонент. Интерфейсы морозить никто не предлагает.

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

[anatolix.livejournal.com]

Ну подожди - вот допустим ты изменил формат индекса, изменив формат структуры, написав код которые его формирует(он где-то в роботе будет работать) и который использует(это где-то в поиске в ражировании). Что именно предлагается сделать 2 или 3 коммита, которые будут по разному проходить review и есть шанс что один из них откатят, а второй забудут или сделать один коммит?

[ex0_planet]

А если на робота задеплоят старую версию, а в ранжирование новую?

[anatolix.livejournal.com]

Деплой это уже отдельное тестирование, такая провека есть, но ты знаешь же что чем позже находишь баг тем дороже это получается, поэтому лучше чтобы работоспособность кода у девелперов не зависила от тестов на deploy которые возможно будут через месяц-два после коммита

[ex0_planet]

Ну, смотри, ты мне сейчас фактически говоришь, что разрезать поиск формату индекса нельзя. Дык ё, не режь его там!

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

[anatolix.livejournal.com]

Я как раз сказал что разрезать поиск по программам нельзя, можно конечно все что работает с индексом отрезать в одну штуку.

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

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

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

[ex0_planet]

> все что работает с индексом отрезать в одну штуку
Например. Но это игра в одни ворота -- я-то не знаю вашей специфики :-)


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


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

[anatolix.livejournal.com]

Да нет никакой специфики. Просто когда мы сейчас пишем код мы так же не знаем где его потом будем изменять, так что это все теоретизация. Есть только набор примеров вида " 5 лет назад заменили все строки на уникод во всем коде "

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

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

[ex0_planet]

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

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

[anatolix.livejournal.com]

Сейчас ни в чем, просто когда начинали писать unicode еще не изобрели.

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

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

[ex0_planet]

Прошло N времени, фейсбук таки заточил mercurial, в связи с чем хочется поинтересоваться: смотрели? прижилось оно в яндексе?

[anatolix.livejournal.com]

Мы на него вяло смотрим, скрипт конверсии сломался на большом файле(там квадратичный diff), времени это поправить пока ни у кого не нашлось, найдется чуть позже.