Как стать автором
Обновить

Комментарии 93

это пост на Хабре, у вас какие-то сомнения в этом?
Чмаки всем в этом чате
:) Вы уверены?
Ну это както маловато для поста что ли, если бы вы привели больше велосипедных решений, проблем с ними и способов как этого избежать с помощью сиcтем контроля версий было бы лучше. И скорее всего пост мало полезно местной аудитории, это больше выглядит как неудачный понт перед {{subjekt}}.
Ага, слово в слово еще до того, как ваш комментарий увидел.
Дайте угадаю вы хотели повторить это?
valplo: Что это, Бэрримор?!
withkittens: Это реабилитационный пост от пользователя с отрицательной кармой, сэр.
valplo: И что он тут делает, Бэрримор?
withkittens: Собирает минусы, сэр.
Пятница вечер, сэр)
А в моей конторе Ртуть используется. А в личных проектах — SVN.
«Я могу обойтись без Git-а, ага»
Пользователи _________________(вставить название своей любимой системы контроля версий) смотрят на вас, как на _________(заполнить в меру своего воспитания).
И что, есть более правильные в современном мире СУВ, чем Git?
В мире IT нет ничего правильного и неправильного, есть только то что полезно использовать в определенных случаях. А термина СУВ нет вообще.
Правильные для чего?
К примеру мне надо уметь externals подключать, причем не весь репозиторий, а только один каталог из него. Git умеет? А SVN умеет.
Причем не надо думать что я против Git. Я за то, чтобы выбирать инструмент, который задачу решает, а не фанатеть от одного и не пользоваться другими только из-за своего фанатизма.
Git умеет… Пакеты называется
Ого! Удивили! Что, кроме submodules появился другой инструмент? Это интересно.
А ссылочку на документацию не дадите? А то что-то не гуглится.
bower
composer
NPM, внезапно
Простите, что ЭТО?
речь о подключении части другого репозитория. С возможность работать с ним через VCS, со всеми фишками типа коммитов и дифа. А вы предлагаете инструмент, который тупо подтаскивает нужные зависимости…
Или вы что-то не понимаете, или я…
Git умеет держать много лет много версий Linux-а…
Наверное, ничего не понимают разработчики Linux-а
Вы вообще поняли о каком функционале я спрашивал?
Вы в курсе как работают submodules в Git? У submodules есть ограничение — подключить можно только репозиторий целиком.
Так вот, есть у Git инструмент с тем же функционалом что и submodules, но БЕЗ этого ограничения?

P.S. Причем тут Линукс, вообще, кстати?
при том, что такая мелочь, как самое популярное ядро ОС при разработке использует Git
НЛО прилетело и опубликовало эту надпись здесь
И что? Или у вас логика работает на уровне «Linux использует Git, а они ж не дураки, значит дураки те, кто не использует Linux».
При чем тут Линукс вообще?
Я попросил решение конкретной проблемы, вы зачем-то Линукс сюда приплели, а озвученную проблему проигнорировали…
P.S. Причем тут Линукс, вообще, кстати?

Я думаю слово интересное ) Ну нравится человеку, что поделать? ;)
Git умеет работать с «подмодулями» (submodules) и часть репозитория склонировать тоже можно. В терминологии git — это называется sparse checkout: документация, пример использования.
Дайте определение слову «правильные» (с) сериал «Посредник»

Практически на любой аргумент в пользу Git, относительно (например)SVN, можно привести контраргумент. Но и на любой аргумент в пользу SVN, относительно Git, так же можно привести контраргумент. Потому что у них диаметрально противоположная идеология использования. Слабые стороны одного являются сильными сторонами другого. И наоборот. А при определённых юзеркейсах они оба сосут у Ртути. А с Солнечной стороны к ним подкрадывается TFS со своими аргументами, тщательно смазанными лубрикантом…
Спор о «правильной» VCS ещё более глупый, чем спор о том, какой ЯП лучше#.
Статья о том, как заработать много минусов за 10 минут)))
За двое суток, вестимо.
Мне интересно это статья для розжига холивара vcs систем или кто-то просто после пятничного пива упал лицом на клавиатуру и случайно получился этот пост? (статьёй это назвать сложно...)
Просто редкий пример хабросамоубийства. Давненько их не было…
нет, это статья для тех, кто обходится без СУП, для, извините, начинающих разработчиков…
Если вы не можете оторваться от SVN до сих пор, или вдруг юзаете «Ртуть» по каким-то личным предпочтениям — вовсе не обязательно минусовать посты про то, что нужно использовать хоть какую-то СУВ. А хоть какая-то для начинающих сегодня — только и только Git
(ну, извините, динозавры, если вашу любимую задел)
это статья для тех, кто обходится без СУП, для, извините, начинающих разработчиков…

Дадада, особенно с пассажем «если ты найдёшь контору, в которой не используется Git — ты попал не в ту контору».
Интересно почему hg вы считаете динозаврной…
нет, динозавра — это SVN…
Меркуриал — просто специфическая штука… и, да, наверное, для специфичеких людей она лучше…
Есть просто такой момент, как: все делают в одну сторону, а самые умные — в другую…
но это тема отдельной статьи :)
НЛО прилетело и опубликовало эту надпись здесь
Чего-чего? Меркуриал — специфичная штука?? Насколько я знаю, в бизнес-среде он используется куда чаще, чем git. У него, в отличие от git, есть очень даже юзабельный GUI. Если он не мейнстрим в open-source разработке, то, как мне кажется, лишь потому, что так сложилось, но уж точно, не потому что он «специфичный».
Из «статьи»:
И если эта статья оказалась для тебя, просто почитай вот это
git-scm.com/book/ru/v1
(я читал это раза 3, прежде чем)


Видимо прежде чем совершить хабро-самоубийство ;)

p.s.
Извините зато, что назвал этот пост статьей…
прощай, vnaz… это явно хабро-самоубийство…
а я ведь еще помню Ваш пост про MVC… но тогда не получилось…
У гита есть одна проблемка, в него нельзя положить много кода. Много — это несколько гигабайт, если что. Это одна из причин, почему в гугле используется не он, а другая система контроля версий.
если вам в репо нужно класть гигабайт кода — это проблема Git-а?!
давычо?!!!
Ну ок. Мне нужно не гигабайты кода туда класть, а гигабайты ресурсов. Скажем мы делаем игру и выбирем VCS для нее. Какую порекомендуете?

Я встречался с индивидами, которые считают что ресурсам контроль версионности не нужен, или как максимум хватит архивов с подписями. Но вы же не такой, да? И сейчас, уверен, предложите отличное решение.
ну, хорошо, если вы пишете игру с гигабайтами версионности, может, Git не подходит…
Много ли людей пишут игры с гигабайтами ресурсов?
(а статья/пост, ваще-т, для программеров, а не для других специфических разработчиков)
Все геймдевелоперы пишут игры с гигабайтами версионности. К примеру, один только пакет ресурсов для магазина Steam весит около 200 мегабайт. Не говоря уж о незапакованных ресурсах.
Даже ресурсы мелкой аркады под гиг занимают. Что-то более серьезное — гораздо больше.

пост, ваще-т, для программеров, а не для других специфических разработчиков

С каких пор программисты живут в своем отдельном мире? Все программисты работают над проектами. И, внезапно, в этих проектах участвуют не только программисты.
Один ваш комментарий лучше другого, если честно :D

Обороты геймдева? Количество геймдев компаний? Количество разработчиков в геймдев компаниях? А что такое программер, а что такое другой специфический разработчик?

Честно говоря у меня просто создается впечатление, что вы нагло троллите бедных людей, которым приходится что-то объяснять аргументированно, а вам пофиг, сидите дальше ржете над нами.
В гит можно положить гигабайты игры, мы это сделали и счастливы.
Сколько времени занимает клон проекта с гигабайтами игры?
Часа два. Через SVN игра такого же размера вычекивается заметно медленнее. При этом мы сейчас работаем над интеграцией git-lfs в нашу инфраструктуру и думаем уменьшить время клонирования минут до десяти, выкинув блобы (в основном, текстуры) в git-lfs.
Я тут на днях клонировал git реп на 500 метров. Клонирование несколько раз падало с ошибкой. Плюнул и склонировал без истории (--depth=1). Время не засекал, но было долго.
Реп с доками к проекту. Отдельных тяжелых файлов там нет.
У нас репа пару гигабайт, а с историей все 70. Часто приходилось шаманить со всякими настройками, чтобы не падало клонирование (количество потоков, размер окна и проч.). Потом это надоело, вот думаем, на что переложить хранение ресурсов. Западены вроде используют какие-то платные решения, ибо где-то читал, что сами разработчики гита не сильно советуют хранить большие объёмы.
Я наслышан хорошего про hg Largefiles и Bigfiles, но еще не пробовал.
Есть же команды вроде git-annex, git-bup, git-fat. Я что-то подобное использую, но судя по всему оно проприетарное и непубличное. Суть в хранении внутри файла хеша или пути к реальному файлу и замещению его содержимым при git-checkout. Оно хуками/атрибутами всё прозрачно делает. Сами большие файлы при этом храняться где-то в другом месте, доступном по сети, и дополнительно выкачиваются для ускорения на будущее, т.е. после инициализации репозитория оно просто работает.
Не все проприетарное. Гитхаб уже анонсировал у себя git-lfs, выше это название уже проскакивало.
Вот кстати и он git-lfs.github.com сам правда не юзал.
И вроде гитхаб или уже использует, или планирует это использовать.
Я понимаю, что ваш вопрос был с подколкой, но, если вам действительно интересно, для ресурсов порекомендую использовать digital asset management systems. Я не знаю, как они по русски правильно называются. Например, посмотрите на Alienbrain, контроль версий там точно есть. Пишу про Alienbrain, т.к. приходилось с ним сталкиваться, возможно есть и более хорошие решения.
ну очевидно, что это проблема VCS, а не моя, у меня проблем нет, я просто выберу другую VCS.
Или типа гигабайты кода это что-то из ряда вон выходящее и говорящее о статусе программиста\ов? Ну давайте прикинь на каком объеме кода работает экосистема гугла… git всё еще самое верное решение, да? без него никуда да?
Я же не написал, что один файл размером в гигабайты. Файлов много, каждый может быть вполне себе нормальных размеров, но суммарно получается уже много. А если вспомнить ещё и про то, что нужно про все предыдущие ревизии тоже помнить… В итоге клонирование репозитория легко может занять часы.
Ну если говорить именно о коде, то лучше git как раз пока не справляется никто. svn я не вижу смысла рассматривать — в нём чекаут одной ревизии занимает больше места чем вся история + чекаут в git и крайне неэффективно лежит на диске, а любая операция требует сети и занимает уйму времени (привет svn log --diff). Кроме того, он не умеет важной фичи которую умел даже cvs: обновляться из одного репозитория, а коммитить в другой, что позволило бы ускорить работу с далёким (в смысле пинга) репозиторием с помощью локального зеркала. У hg таких глобальных проблем нет, но он просто медленнее. Это всё показала практика работы с репозиториями FreeBSD (гигабайт чекаут, гигабайт полная история сжатая git).

А что до гугла — то не знаю как сейчас, но когда я там работал там использовался perforce. И это был просто невообразимый ад.
Локальные размеры разве имеют какое-то значение? Пара лишних гигов — ни о чем.
Что мешает обновиться из одного SVN репозитория и коммитить в другой? Relocate отменили?
> Локальные размеры разве имеют какое-то значение? Пара лишних гигов — ни о чем.

О чём. Во-первых, эти пара гигов определяют влезут ли горячие данные в кэш файловой системы, и будет ли скорость работы с репозиторием определяться диском или памятью. Во-вторых, даже касательно дисков на таких объёмах они имеют значение — у меня на ноутбуке ssd забит в основном репозиториями, и 1.5 раза это большая разница. В-третьих, если уж собрались сравнивать, то напомню что со стороны git мы считаем полную историю, а я даже не хочу знать сколько места будет занимать вся svn история такого репозитория. В-четвёртых, просто неплохой показатель адекватности vcs.

> Что мешает обновиться из одного SVN репозитория и коммитить в другой? Relocate отменили?

Вы серьёзно предлагаете relocate перед и после каждого коммита?
>>Вы серьёзно предлагаете relocate перед и после каждого коммита?
Нет, не предлагаю. Лишь указываю на фактическую возможность. В целом я отношусь к тому типу людей, которые вообще не делают локальных бэкапов в силу использования фонового бэкапера, который позволяет без использования VCS откатиться на любой момент времени.
> Лишь указываю на фактическую возможность.

Ну так на практике от этой возможности толку нет.

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

VCS не имеет отношения к бэкапам.
>> VCS не имеет отношения к бэкапам.
Верно. Но функционал локальных коммитов в 90% случаев совпадает с бэкапами.
Ничего подобного.
Представьте, что мне нужно держать 5 экземпляров одного дольшого-большого репозитория в разных состояниях (например, на разных ветках). С git и hg я могу один раз сделать пулл с удалённого сервера, а в остальных 4 сделать пулл с первого. Более того, эти репозитории не буду занимать в 5 раз больше места, потому что при локальном клонировании git и hg умеют использовать хардлинки.
Я не агитирую за SVN. Я лишь указал, что не сталкивался с указанными минусами SVN, потому что нет требований(лично меня) которым бы он не удовлетворял.
На мой взгляд, выбор VCS — достаточно сложная вещь и идеальной VCS пока нет.
Я выбрал SVN для личных проектов, потому что мне нужны были externals из каталога репозиториев и только SVN мне это дал. При этом я понимаю что в больших компаниях он не будет так удобен как раз из-за отсутствия возомжности локального коммита. У меня то такого поняти нет, учитывая что SVN находится на моем сервере и всегда доступен.
> С git и hg я могу один раз сделать пулл с удалённого сервера, а в остальных 4 сделать пулл с первого

JFYI, свежий git умеет несколько рабочих директорий из одного репозитория, т.е. pull нужно делать только один раз.
Помоему это не на этот сайт, а на какой-нибудь zadolba.li или ithappens.me, что лучше подходит… Ну или в бложик личный…
ИМХО чувак пиарит книгу. Стиль изложения и отношения к пользователям других VCS очень пересекается в книге и текстах «автора».
Ну не знаю, по стилю изложения просто бомбануло :)
Давненько такого не было :)
Если пишете на хабре, пишите хоть аргументы какие, сравнения, или хоть что-то.
А статьи вроде «ты не используешь git, а знаешь какой он крутой», как мне кажется, для другой аудитории.
Читатели хабра (я надеюсь) давно знают про разные VCS, про их преимущества и недостатки в сравнении друг с другом. Все-таки большинство с этим каждый день работает…
Это как прийти на сайт маляров, и сказать: «ты знаешь, что можно красить КИСТОЧКОЙ?»
Почти верно, только статья про то, что «Ты знаешь, что кисточки можно хранить так, что любой маляр, которому ты дашь доступ, сможет пользоваться твоей кисточкой так, что не насрёт на твоё полотно»…
Почувствуйте разницу, если :)
Имелся в виду инструмент, а не объект для хранения
Я думаю там что-то похардкорнее кофе…
А если контора использует СУВ не Git — ага, это таки призначек

«Призначек» чего?
А что, толковая статья. Можно sed'ом (я могу обойтись без sed-а, ага) заменить «Git» на другое слово — и готово, можно новую статью публиковать. Я вот пару заготовочек сделал.
Docker
Я могу обойтись без Docker-а, ага
Разработка*
Конечно… Если ты умеешь програмировать, зачем тебе Docker?
Ты вполне умеешь управлять своими машинами с помошью скрипта, и прекрасно понимаешь, какое имя контейнера соответствует состоянию твоего проекта.

Ты вполне в состоянии запустить именно тот контейнер, который содержит то состояние проекта, на которое нужно откатиться, а потом создашь новый контейнер, немного отличающийся от контейнера версии 2.0, и назовёшь его в2.1+фича1_и_2_из в1.арх

Потом, о щастье, в твоём проекте появился поддаван или даже партнёр.
Ты, конечно, сможешь ему объяснить, что имя контейнера нужно читать так:
первые символы номер текущей версии, а какие-то тонкости можно описать в оставшихся символах имени контейнера, или в комментариях к контейнеру.

Просто всё это пройдено разработчиками Linux-а, за много-много лет (с 2013 года, посчитай сам).
И чтобы не придумывать все эти правила, разработчики Linux решили сделать штуку, которая будет понятна всем, кто хочет понять, и даже дать эту штуку любому желающему (даже если ты разработчик не Linux, а, например, 1С, или Postgress, или твоего личного нового Гуглобука).

И да, ты если разработчик, и ищешь работу, вряд ли ты найдёшь нормальную работу в конторе, которая не использует Docker.
Хуже другое… Если ты найдёшь контору, в которой не используется Docker — ты попал не в ту контору.

И если эта статья оказалась для тебя, просто почитай вот это
ru.wikipedia.org/wiki/Docker
(я читал это раза 3, прежде чем)

ФП
Я могу обойтись без ФП, ага
Разработка*
Конечно… Если ты умеешь програмировать, зачем тебе ФП?
Ты вполне умеешь управлять своим кодом с помошью объектов, и прекрасно понимаешь, какое имя метода соответствует состоянию твоего объекта.

Ты вполне в состоянии запустить сконструировать объект именно того класса, который содержит то состояние проекта, на которое нужно откатиться, а потом создашь новый метод, немного отличающийся от метода версии 2.0, и назовёшь его в2.1+фича1_и_2_из в1.арх

Потом, о щастье, в твоём проекте появился поддаван или даже партнёр.
Ты, конечно, сможешь ему объяснить, что имя метода нужно читать так:
первые символы номер текущей версии, а какие-то тонкости можно описать в оставшихся символах имени метода, или в комментариях к методу.

Просто всё это пройдено разработчиками, за много-много лет (с 1959 года, посчитай сам).
И чтобы не придумывать все эти правила, разработчики решили сделать штуку, которая будет понятна всем, кто хочет понять, и даже дать эту штуку любому желающему (даже если ты разработчик не Unix, а, например, 1С, или Postgress, или твоего личного нового Гуглобука).

И да, ты если разработчик, и ищешь работу, вряд ли ты найдёшь нормальную работу в конторе, которая не использует ФП.
Хуже другое… Если ты найдёшь контору, в которой не используется ФП — ты попал не в ту контору.

И если эта статья оказалась для тебя, просто почитай вот это
Функциональное программирование — Википедия
(я читал это раза 3, прежде чем)

Напомнает легендарную пасту про Python (в кэше гугла, так как с лурком какие-то проблемы).
Спасибо, доставило ещё больше удовольствия, чем оригинал :)
(в кэше гугла, так как с лурком какие-то проблемы).
— видимо связано с этим
Автор, откатитесь до коммита, который был сделан перед этой статьей.
Хм. Почему солнце зажглось именно на GIT? Да он хорош и популярен, но автор незнает, что еще до разработки Linux уже существовали системы контроля версий? Тот же CVS старше Линукса.
НЛО прилетело и опубликовало эту надпись здесь
Изящный способ выпилиться с хабра.
Тролли… На хабре… Интересно )
Это логичные люди, которые пользуют «неgit», которых обозвали _нелогичными_. Без аргументации. Но со «чмаками».
«К середине фильма создалось впечатление, что Колчака убьют».
Таки вы не поняли, я про автора статьи )
Не, это не тролль. Это тэнно-хэйка-банзай пролетал.
Все это клёво, но кто такой «поддаван»? У меня есть несколько версий, но что-то я в них сомневаюсь:
1. Собутыльник («поддавать» в одиночку — признак алкоголизма);
2. Просто вечно «поддатый» сотрудник;
3. Тот, кто придет и «наподдаст» за то, что юзаешь СУВ не Git.
На этом мои варианты исчерпаны =/
4. «поддаван» — это помощник парильщика в бане, который отвечает за то, чтобы вовремя или по команде парильщика поддать парку.
В зависимости от проекта использую git, svn, mercurial, bazaar… Но душа лежит к fossil.
Аргументы приводить не буду, ибо смысла нет.
Крутое само-хабро-убийство :)
Ну, автор! Ну, блин жеж! Даже я так не палился, почти совершив двойной хабрасуицид…

Ну ведь даже иэ этой темы можно было бы выжать что-нибудь интересное. Историю поучительную написать, рассказ. Примеры привести. Ну хоть сам берись, сиди и пиши.
Я понимаю, конечно, что на волне эйфории/злости/прочих_чувств_и_стремлений можно много чего захотеть понаписать и свои ошибки самому себе видно хуже чем ошибки других… Но посту ровно сутки уже, а он до сих пор висит.

Давненько такого не было… Хорошо ещё что на ГТ, а не на «основном» портале.
*вот… блин… не знаю с чего я решил что это пост на ГТ… верно, не выспался сегодня… Тогда вообще понять не могу как пост попал в ленту. Неужели, модераторы решили саморасстрелу не мешать?*
Смутное ощущение, что автору подарили акаунт. Каждый комментарий можно перефразировать в «накидайте минусов, кому не жалко».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории