Search
Write a publication
Pull to refresh
18
0
Загурский Сергей @shortcircuit

Пользователь

Send message
Нет, я не путаю понятия. Судя по всему, ограничения о которых я говорил, уже не актуальны: blog.oio.de/2014/02/06/better-support-for-shallow-clones-in-git-1-9/
Использование git submodules — это уже компромисс по удобству и подводным граблям. Плюс, доброй половине разработчиков таки нужен весь набор.
Размер и неразборность проекта, безусловно, не ускоряют разработку, да. Но это специфика нашего направления.
История ~500K коммитов. Бинарных блобов минимум. Полная история в git'е, как я сказал выше, занимает несколько терабайт.
При всей моей любви к DVCS, всё же существуют валидные случаи, когда git хуже, например, svn. Если разрабатывается огромный проект и объём истории весит порядка нескольких терабайт, то тупо непрактично заставлять каждого разработчика держать копию всей истории локально. Насколько мне известно, git пока ещё не умеет полноценно работать с частичной историей.
И если поток, который “обогащает” записи в tail (геолокация по ip, мапирование OS, браузеров), запишет в удаленную структуру данных, будет бобо. Также известное как SEGFAULT.


Я вас, возможно, немного расстрою. Но «бобо» будет SEGFAULT'ом далеко не всегда. Более точное описание: undefined behavior. В вашем случае SEGFAULT будет редкой удачей, позволяющей относительно быстро понять в чём проблема.
Есть такая практика под названием «до первого столба». Это когда в коде есть известная необрабатываемая ситуация, которая валидна, но, как кажется разработчику, не должна возникнуть никогда, на возникновение которой стоит некий guard, подающий недвузначный сигнал. Если бы у вас SEGFAULT был гарантированно, то можно было бы считать, что вы применяете эту практику, сэкономив на кодировании синхронизации. В вашем же случае, вы, скорее всего, даже не узнаете, что «бобо» случилось.
2

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Registered
Activity