kika: (default)
kika ([personal profile] kika) wrote2013-10-17 12:09 pm

Subperversion

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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