Разработчики из Microsoft столкнулись с проблемой масштабирования Git: как оказалось, на платформе Windows приложение не в состоянии работать с очень крупными репозиториями. Так, например, исходные коды Windows содержат 3,5 миллиона файлов, которые в сумме занимают более 270GB. В одном из крупных проектов Microsoft операция clone выполняется 12 часов, checkout - 3 часа, status - 8 минут, commit - 30 минут. Поняв, что так работать невозможно, Microsoft создала (https://blogs.msdn.microsoft.com/visualstudioalm/2017/02/03/.../) GVFS - слой виртуализации файловой системы для Git, который позволяет Git думать, что файлы находятся на месте, но подгружаются они только тогда, когда реально нужны.
С помощью предложенного решения для репозиториев, размещённых в окружении Windows, удалось ускорить выполнение операции clone в 144 раза, checkout в 360 раз, status в 120 раз, commit в 140 раз.Исходный код проекта опубликован на Github (https://github.com/Microsoft/gvfs) под лицензией MIT. В настоящий момент сборка GVFS поддерживается только для Windows 10. Для корректной работы репозиториев GVFS рекомендуется использование развиваемого (https://github.com/Microsoft/git) в Microsoft модифицированного ответвления от свободного продукта git-for-windows (https://git-for-windows.github.io/).
URL: https://blogs.msdn.microsoft.com/visualstudioalm/2017/02/03/.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=45978
Круто конечно, но тенденция нездоровая.
Что крутого то. Это же костыль. Вместо того что бы запатчить гит, что бы он не хотел файлов, которые в данный момент не нужны, они сделали виртуальную файловую систему которая эмулирует, что эти файлы как будто-то бы есть. Типичный МС-вей.
>Что крутого то.Работает быстрее
>Это же костыль.
Костыль работает быстрее
>Вместо того что бы
Как знать, что будет в будущем.
>Типичный МС-вей.
Кто же им может запретить?
С чего это он быстрее найтивной реализации?
ты никак не пропатчишь гит - он ущербен by design. Набор не очень мощных костылей. github вон тоже внешнюю приблуду написал для хранения крупных файлов. Гит покрывает только очень простые сценарии использования. Зато его можно написать за месяц.
Будь тоньше и к тебе все потянутся.
А станет круглее и на него совы сами натянутся.
> он ущербен by design.Нет - ты.
Да правильно он всё говорит
"исходные коды Windows содержат 3,5 миллиона файлов,"
PCB, SOA и прочее не являются исходным кодом, ущербен сам проект, а не система контроля версий исходных файлов
хм.. ну да запилить опционально в сам гит такой режим работы было-бы неплохо.. но gvfs пусть отдельно поставляется. думаю в апстрим возьмут поддержку протокола..
> Вместо того что бы запатчить гитА нахрена его патчить? Мелкомякиши сделали вид, что не осилили:
git clone --depth=1Но я не думаю, что они тупые. Это идёт целенаправленная централизация git, напрямую им бы никто не позволил, а с понтом "новая файловая система" - пипл схавает.
Ну а то, что контроль над файлами остаётся у хозяина сервера, тихо умалчивают.
Ой, я в линуксе 2 день. Простите за вопрос. А что, без "git clone --depth=1" репа целиком не синхронизируется на клиента?
> Ой, я в линуксе 2 день. Простите за вопрос. А что, без
> "git clone --depth=1" репа целиком не синхронизируется на клиента?Наоборот, без "--depth=N" репа полностью синхронизируется, поэтому долго.
Если же задана глубина, то синхронизируются только N последних коммитов (снимков).Для разработчика (и тем более пользователя) все коммиты не нужны, достаточно нескольких последних, даже одного последнего, как в моём примере, тогда клонирование происходит очень быстро. Ну а потом новые коммиты подгружать git pull.
Это был такой тонкий троллинг, который мсье не понял. Уж мне-то можно верить, троллинг — моя профессия.А суть сказанного: depth=1 ограничит количество коммитов, но не файлов в рабочей копии. А их, как жалуется мс, аж 3.5 млн.
> Это был такой тонкий троллинг, который мсье не понял. Уж мне-то можно
> верить, троллинг — моя профессия.
> А суть сказанного: depth=1 ограничит количество коммитов, но не файлов в рабочей
> копии. А их, как жалуется мс, аж 3.5 млн.Я по практике говорю, что git clone многократно ускоряется, если добавить depth=1.
Что же касается 3.5 млн файлов, то как, скажите, бедненький Торвальдс мучается с этим вашим gitом? Ведь linux kernel содержит много файлов!
Если мякишей так припёрло, пусть используют централизованный SVN, и не суют свои поганые ручонки к распределённым системам.
> Ведь linux kernel содержит много файлов!совсем другого порядка величина. В линуксе столько строчек, сколько в репах мс (по их словам) файлов.
> Если мякишей так припёрло, пусть используют централизованный SVN
большие компании так и делают: используют один централизованный репозиторий для всего кода. Зачем мс взяла изначально неподходящий инструмент, можно только гадать.
> и не суют свои поганые ручонки к распределённым системам.
как бы, вольны делать, что хотят. Мне тоже не нравится этот их embrace линукса, а вот сейчас, extend гита. Но запретить им нельзя.
т.е. когда линухоиды и бздяшники костыль на костыле делают, это нормально, это unix-вей?;)
> т.е. когда линухоиды и бздяшники костыль на костыле делают,270 гиг в _одном_ репЕ (чекауте?!) от любого из помянутых предъяви, не сходя с места, или б----!
> это нормально, это unix-вей?;)
Иди в винду, неумный.
> Microsoft представила виртуальную файловую системуWinFS v7.0? Они все никак не могут остановиться изобретать свою файловую систему...
Всё тот же "Embrace, extend, and exterminate"
If you can’t beat em, join em
If you can't join them, sit in the dark corner and cry...
Добро пожаловать в филиал двача на Оупеннете? Комментарии вообще невозможно стало читать, ср-ч какой-то детский без конца.
>Комментарии вообще невозможно стало читать, ср-ч какой-то детский без конца.Согласен! А особенно "невозможно стало" остановиться с---ь в к-мментах, читать - не читать, но не писать -- совершенно невозможно. Куда катится этот ... МирЪ, бро!?
GVFS will work with any git service that supports the GVFS protocol. For now, that means you'll need to create a repo in Team Services (https://www.visualstudio.com/team-services/), and push some contents to it. There are two constraints:
Your repo must not enable any clean/smudge filters
Your repo must have a .gitattributes file in the root that includes the line "* -text"
т.е. для гитхаба все эти "теперь status меньше чем за восемь минут" работать просто не будут и внутри там дракон (-text)
Ну этой проблемой Microsoft займётся, когда купит GitHub ;-)
А, ну то есть, MS выпустили очередную ерунду, нужную только им самим и, по традиции, изображают из себя лучших друзей OpenSource.
> нужную только им самимТы не поверишь, но так делают все...
суровая правда про ntfs и реализацию кэшей в ведре. не гит мерять надо было, а скорость загрузки своей какашки
Вот и я тоже думаю, лучше бы выложили на GitHub вместо этого костыля те самые "3,5 миллиона файлов, которые в сумме занимают более 270GB", чтобы каждый мог проверить скорость работы Git на подходящей FS.
А ты сам прикинь. git-checkout для /usr/portage у меня занимает ~6 минут. /usr/portage при этом меньше 2Gb -- там сложно сказать точнее, потому что emerge там ещё и локальные данные хранит. Если предположить, что время checkout'а линейно зависит от объёма, то:6 минут * 270/2 = 13.5 часов. Они пишут про 12. То ли ext4 тормознее ntfs, то ли у меня канал в интернет тоньше, чем у ms. Хотя, ещё может быть emerge в /usr/portage хранит слишком много всего. Но, во всяком случае, это отбивает у меня всякое желание проверять время 270-гигабайтного чекаута экспериментально. Я в дайлап времена накушался по самые гланды такого, сутками вытягивая из интернетов слакварные iso'шки.
Исходные коды Windows по твоему лежат в интернетах?
> Исходные коды Windows по твоему лежат в интернетах?снегерь из urandom файликов. будет отличаться не сильно от того, что ты зачем-то хочешь видеть в интернетах. замерять Скорость Великого git будет достаточно и на таких данных.
> снегерь из urandom файликов. будет отличаться не сильно от того, что тыДля тестов, думаю, можно чего не такое токсическое, как в сабже, и больше похожее, чем urandom, на таки исходники найти.
http://cdimage.debian.org/debian-cd/current/source/iso-dvd/
Распаковать, закоммитить, git-gc-сжать (осторожно, Микаэль, электрическое отопление дОрого!) -- и врерёд, на тестирование checkout/clone-ов.
Но по-любому медленно _будет_. Нельзя 270Гб исходников, сотни тысяч файлов за 1-2 секунды _тупо_ создать на HDD. И на SDD, наверное. Почти уверен, что и на tmpfs.
+++Новость позитивная. Есть нажежда, что они под собственным весом -- того.
> зачем-то хочешь видеть в интернетах. замерять Скорость Великого git будет достаточно
> и на таких данных.
>[оверквотинг удален]
> /usr/portage при этом меньше 2Gb -- там сложно сказать точнее, потому
> что emerge там ещё и локальные данные хранит. Если предположить, что
> время checkout'а линейно зависит от объёма, то:
> 6 минут * 270/2 = 13.5 часов. Они пишут про 12. То
> ли ext4 тормознее ntfs, то ли у меня канал в интернет
> тоньше, чем у ms. Хотя, ещё может быть emerge в /usr/portage
> хранит слишком много всего. Но, во всяком случае, это отбивает у
> меня всякое желание проверять время 270-гигабайтного чекаута экспериментально. Я в дайлап
> времена накушался по самые гланды такого, сутками вытягивая из интернетов слакварные
> iso'шки.блин яб к портежу вот эту фичу прикрутил..
Portage уже давно умеет чекаут из гита делать, но там есть свои нюансы...
Не верно. О каких локальных данных вы говорите? Тех, что в /var/cache/edb? /var/db/pkg? ) что можно _локально_ хранить в каталоге, каждый раз мучаемом rsync (exclude distfiles, разумеется)?
> Не верно. О каких локальных данных вы говорите? Тех, что в /var/cache/edb?
> /var/db/pkg? ) что можно _локально_ хранить в каталоге, каждый раз мучаемом
> rsync (exclude distfiles, разумеется)?Ну... Эмм... Окей. Соврал. Простите не хотел.
Да, я имел то, что в /var/cache/edb и в /var/db/pkg. distfiles я вычел из объёма.
При чем тут канал интернета к чекауту? Чекаут это локальная операция. От объема не зависит (на нормальных ФС), зависит от количества файлов.
> При чем тут канал интернета к чекауту? Чекаут это локальная операция. От
> объема не зависит (на нормальных ФС), зависит от количества файлов.Теперь же Вы будете "гонять" MS-GVFS-ик прямо с "хостинга" в MS-Azure! По интернетику... .... ..... Отдел прожаж маркетинга уверен!! </новая Реальность>
> При чем тут канал интернета к чекауту? Чекаут это локальная операция. От
> объема не зависит (на нормальных ФС), зависит от количества файлов.А я сказал про чекаут? На меня в тот момент видимо какое-то потемнение нашло. Я имел в виду clone. Простите.
> суровая правда про ntfs и реализацию кэшей в ведре. не гит мерять
> надо было, а скорость загрузки своей какашкиты можешь повторить их "эксперимент". на рассово-верной (ТМ) по-твоему авторитетному мнению FS, и показать что на ней чекаут/клон/etc делаются доли секунды. Объем только и примерное кол-во файлов не забудь повторить тоже, дабы не обгадиться сильно круто.
Ищешь обгадившегося? Начни с себя. И не забудь парочку бенчмарков по ntfs сделать.
> "тормозит" и "не зависимо от fs". но ты продолжай верить вДа, "270Гб исходников, сотни тысяч файлов [не] за 1-2 секунды" -- независимр от FS и ядра.
> то, что, например, ntfs сильно хуже этих ваших толп ext*, fs
> от женоубийцы и прочих.На "нормальных" объёмах под эти ваши пердовые технологии тормозят и требуют костыляния, что есть сил:
+ https://git.kernel.org/cgit/git/git.git/log/?qt=grep&q=windows+++"is only possible with a permanent serious drain of resources." ... "a permanent drain of developer energy and fun into supporting Windows" http://lists.gnu.org/archive/html/guile-devel/2017-02/msg000...
---Впрочем, да! CVS спасает?
Создать GVFS оказалось легче, чем объяснить всем индусам, что необязательно выполнять команды git от корня репозитория?
:-) Отчего так кажется, что вся суть MS GVFS сводится к copy-on-write?...
В смысле, checkout on access...
А про clone --no-checkout, sparse-checkout и хардлинки для .git/ в прочих фс, наверное, авторам вообще лучше не сообщать))
Интересно, сколько времени у них запускается Clion на этих пресловутых "3,5 миллиона файлов, которые в сумме занимают более 270GB". Не в Vim'е же они разработку ведут.
У них же MSVS, зачем им Clion
Так они раньше и не гитом пользовались, а своей поделкой, а вот однако жке
CLion это ты отлично пошутил
эти дауны просто не в курсе что в мире существуют OS с sysdig/strace и возможностью профилирования внутри ядра. основные тормоза в git - это stat и open syscalls, порядок вызова которых легко варьируется cmdline ключами. но если уже kernel кеши не в состоянии отдать stat/open быстро, то тут уж ничем не помочь. следующий этап, я так понимаю это запил альтернативы для их убогого nt ядра
А чем конкретно ядро NT убого?
> А чем конкретно ядро NT убого?Насчёт технических проблем мои дровишки могли устареть (хотя что-то непохоже), а вот про организационные изнутрей, например: http://blog.zorinaq.com/i-contribute-to-the-windows-kernel-w.../
Патченный Гит для блоба это новость? Серьёзно? Ну быстрый, но проприетарщина же жуткая https://github.com/Microsoft/GVFS/blob/master/GvFlt_EULA.doc...
Текст лицензии в .docx... Microsoft такая Microsoft.
> Microsoft создала (https://blogs.msdn.microsoft.com/visualstudioalm/2017/02/03/.../)
> GVFS - слой виртуализации файловой системы для Git, который позволяет
% whatis gvfs
gvfs-cat(1) - Concatenate files
gvfs-copy(1) - Copy files
...
gvfs-tree(1) - List contents of directories in a tree-like format
gvfs(7) - GIO virtual file system
https://packages.debian.org/jessie/gvfs
> gvfs is a userspace virtual filesystem where mounts run as separate processesАй молодцы! Как обычно, даже не поинтересовались, используется ли такое у "новых самых лучших друзей".
Ведь если нет трейдмарка, значит можно использовать!
Они придумали Git LFS и еще кучу таких.
> В одном из крупных проектов Microsoft операция clone выполняется 12 часов, checkout - 3 часа, status - 8 минут, commit - 30 минут.Интересно, сколько те же операции заняли бы под linux на ext4.
Наверняка есть способы избежать такого огромного репо
> Наверняка есть способы избежать такого огромного репоZFS lz4 + dedup, BTRFS lzo + dedup
>> Наверняка есть способы избежать такого огромного репо
> ZFS lz4 + dedup, BTRFS lzo + dedupОпа, умник в треде.
Главное, что их нет во всем обсуждении, так победим!
Ты бы спросил лучше у Led как правильно, он бы не отказал поделиться богатым опытом, сразу бы стало понятно кто тут умник, а кто шарит в теме.
> Ты бы спросил лучше у Led как правильно, он бы не отказал поделиться богатым опытомА у него действительно богатый опыт, хоть этого со стороны умника, бегающего тут в интересах некрософта, и не разглядеть. Спросите его про winhpc, например.
> Наверняка есть способы избежать такого огромного репоТише, тише!! Кто сказал "пекадж менаджер"?? Ш--ш-ш-ш! Они же услышат. И расстроятся... </грешно над убогими, но над этими - нужно>
Думаю, им оказалось проще придумать костыль, чем объяснить своим индусам, как писать модульный код и пользоваться субмодулями или системами управления зависимостями.
270Gb сорцы windows... что мешает разбить на модули и держать в разных репозитариях?- юниксвей
- модульность
- микросервисыMS эти слова видимо незнакомы
> 270Gb сорцы windows... что мешает разбить на модули и держать в разных
> репозитариях?
> - юниксвей
> - модульность
> - микросервисы
> MS эти слова видимо незнакомыMS не ищут лёгких путей, они ищут путь к кошелькам пользователей!
Именно, так как MS коммерческая компания.
И она будет всегда пытаться заработать.
> что мешает разбить на модули и держать в разных репозитариях?Это типа "мы изобрели то, что давно есть в OpenSource, только хуже"... Ну и как тогда это продавать? Неее, энтерпрайз не для того, чтобы все было просто и работало. Он, чтобы за деньги продавать, причем одно и то же по нескольку раз.
Даже линух уже отходит от этих устаревших концепций (см. systemd).
Оно конечно забавно, но какие альтернативы?
Попробовали во времена Windows NT 3. К версии 4 всё стало тяжёлым и почти монолитным.
столкнулись с проблемой масштабирования Git?ключевые слова здесь наверное всё-же и "на платформе Windows". то-есть очередной костыль для своей кривой платформы, чтоб не выглядеть идиотами
NTFS конечно медленно с мелкими файлами работает, но в обычном Git операция clone репозитория в 270 Гб на любом системе будет часы занимать. Идея виртуального слоя хорошая, если бы не привязанная к Windows и файловой системе реализация.
>очередной костыль для своей кривой платформы, чтоб не выглядеть идиотамиМожет, и выгладели бы идиотами на костылях, если бы все не знали, что они ни то, ни другое, а нежить, отравляющая нашу жизнь токсическими отходами -- своими "продуктами" и "оперсорсиками".
Модульность разработки в голову эффективных манагеров все ещё не может втиснуться.Поэтому чинить будем там, где не ломалось.
> Модульность разработки в голову эффективных манагеров все ещё не может втиснуться.
> Поэтому чинить будем там, где не ломалось.Поэтому продавать будем под видом решения созданных предыдущими продажами проблем -- новые проблемы, чтобы создавать неотвратимость следующих продаж. #ТехнологииМайкрософт
1) Кто им разрешил использовать Git :)Вдруг там в исходном коде есть код Микрософт или SCO
2) Использовать Git сервер на Linux им религия не позволяет или Билл Гейтс?
3) Хотелось бы посмотреть действительно тесты этого же репозитория на разных файловых системах на Линукс.
Очередной пользователь Chrome? Настолько отупели без адресной строки, что мысль свою не можете понятно выразить? Или в написании сообщений вам гугл или яндекс автоматически дописывает слова? Скоро говорить будете со смартфоном в руках, который будет добавлять окончания слов к вашему мычанию.
>[оверквотинг удален]
> Слушай, деятель, ты все сообщения в расках новости запоминаешь или только те
> что тебе нравятся? То, что фанбои линукса, чмырят других на основании
> своей необразованности это по-твоему нормально? Если фаныты линукса очевидно не могут
> использовать рассово-верным образом chrome, но пишут чушь, тебя это никак не
> задевает по сравнению с неумением выразить мысль или отупением аж от
> адрестной строки которая есть внезапно везде, а том чиле и в
> православном chromium, где свякие посиковики тоже дописывают свои слова? Или ты
> против всего всего что содержит адресную строку? Поясни уже свою позицию,
> а то уже непонятно ты тот же идиот, что писал про
> микрософт или новый!11Ну кто же кого чмырит-то? Я просто помню, что было время, когда Микрософт чмырила Линукс и открытое ПО заявляя, что это само зло. И тогда их никто не трогал. Это микрософт наускивала своего партнёра SCO, чтобы те открывали судебныетяжбы против компаний продвигающих Линукс.
http://www.algonet.ru/?ID=291155
Почему я должен забыть несколько лет гадостей от Микрософт в сторону Линукс?
Кто об этих гадостях микрософт знает, тот скорей всего воспринял мои слова ка стёб. За счёбом был и реальный третий вопрос, хотелось бы сравнить скорость тех же операций с теми же файлами, когда сервер и клиент Линукс. В том же ssh при использовании копирования с виндовс на Линукс были раньше жуткие тормоза . Кроме фактические единственной NTFS в винде, в линуксе есть что пробовать.
В Хроме-Яндекс-Амиго-Опера нет адресной строки по умолчанию, есть умная строка! В поисковиках если отключен javascript никаких подсказок не будет. В поисковой строке Firefox-IceCat-TorBrowser я всегда отключаю "отображать поисковые приложения". Так что у меня там в принципе никаких подсказок нет. Да и системы поиска по умолчанию я обычно
удаляю(кто знает чего там Firefox Foundation дополнительных скриптов надобавляла) захожу https://duckduckgo.com/html и добавляю эту поисковую систему(без всяких суггестион) и делаю её по умолчанию. Так что DuckDuckGo HTML в принципе у меня ничего не подсказывает, даже если я потом в открывшемся результате поиска в поисковой строке изменю слова, то мне тоже ничего не подскажется. Чаще всего и жаваскрипт у меня тоже отключён... Если обиделись, но являетесь всё таки пользоватем умных строк в любом браузере, то ничего тут не поделаешь, это моё мнение. Когда за день видишь несколько раз видишь, что пользователи не используют адресную строку ,а чаще всего адрес вводят полностью в поисковое поле это тупизм чистой воды! Или переключаются на русский и пишут в полоумной строке нужный адрес полностью это тоже тупизм.
> Если фаныты линукса очевидно не могут использовать рассово-верным образом chromeЧё-то Вы больно много по разным темам за него распереживались. Пора сработать п.7 http://wiki.opennet.ru/ForumHelp
Как говорит герой одного российского мультсериала: "Укуси меня бжчала!". Micro$oft использует Git для разработки Windows !? O_O
> Как говорит герой одного российского мультсериала: "Укуси меня бжчала!". Micro$oft использует
> Git для разработки Windows !? O_OА фрибээсдэшники-то и не знают! :-Q ><LLL>
Гентушнег, если чё :)
> А фрибээсдэшники-то и не знают! :-Q ><LLL>Страшно подумать, что с тобой будет, когда их по твоему хотенью не станет.
>> А фрибээсдэшники-то и не знают! :-Q ><LLL>:1---^^
> Страшно подумать, что с тобой будет, когда их по твоему хотенью не
> станет.Выпью, чего ещё тогда дохтур разрешит, за здоровье многострадального КореТиима:
+ https://www.opennet.ru/openforum/vsluhforumID3/68588.html#53 //6.5 лет тому //да, Дилона не поделу помянул--
+ https://www.opennet.ru/openforum/vsluhforumID3/108834.html#24 //.5 года и FreeBSD major++
+ https://www.opennet.ru/openforum/vsluhforumID3/109353.html#347 //пора переосновываться?![Л] См.также
https://www.opennet.ru/openforum/vsluhforumID3/104546.html#34
https://www.opennet.ru/openforum/vsluhforumID3/109353.html#534 //"с кем другим" -- про приписывание мне --- своих? проекций??
https://www.opennet.ru/openforum/vsluhforumID3/108185.html#28 + #29 + #98 ...а не, не то. Это больше к MS GVFS-у... О! Онтопик же -- фришники GOTO :1 в нетерпеньи-ожиданьи.
О да! Уж MS-то знает, как пропатчить git под Windows 😆
О_о, кажется git закроется, как и процы Alpha, Nokia...
> О_о, кажется git закроется, как и процы Alpha, Nokia...Шикарная идея, как сломать буилды уинды! Надо обмозговать!11
Зачем решать проблему? Мы создадим КОСТЫЛЬ!
И, к слову, GVFS уже давно есть: https://ru.wikipedia.org/wiki/GVFS
МС в своем репертуаре.
У Git есть недостаток: он не умеет делать частичные клоны из репа, например как это умеет SVN.
Это действительно by design и по-нормальному не фиксится.
> У Git есть недостаток: он не умеет делать частичные клоны из репа,
> например как это умеет SVN.
> Это действительно by design и по-нормальному не фиксится.Открой для себя:
git clone --depth
git submodule --depth
Учись студент!git clone --depth=1 https://github.com/Microsoft/gvfs.git
SVN этого никак не умеет.
А может ты имеешь в виду склонировать одну директорию?
Ну типа src склонировать, а include нет.
Так смысла в этом нет.
Если директории независимы, то бесполезно их пихать в одну репу (git help submodule).
Если зависимы, то бесполезно их по отдельности клонировать.
>SVN этого никак не умеет.вобще-то svn по-другому не умеет
он всегда делает checkout одной версии, для смены версии нужно обращаться к серверу за новыми данными.
> Исходный код проекта опубликован на Github под лицензией MITТам не MIT. Там обычный EULA, причём запрещающий использовать Продукт™ в виртуальных живых (!) системах.
MIT там лежит потому, что часть кода под MIT, а MIT требует упоминания авторов кода и текста лицензии.
Минуточку. А как же их любимый и рекламируемый Team Foundation Server?
Забросили, как silverlight и иже с ними? Узнаю Microsoft.
> как же их любимый и рекламируемый Team Foundation Server?Одно другому не мешает — в 2013-й версии TFS добавили поддержку Git в качестве системы контроля версий. TFS давно перестал быть исключительно VCS и превратился, в лучших традициях ънтърпрайза, в комбайн "и швец, и жнец, и на дуде игрец".
Вот интересно, адо перехода на Git они чем пользовались? В предыдущей VCS таких проблем как с Git не было что ли?
> Вот интересно, адо перехода на Git они чем пользовались? В предыдущей VCS таких проблем как с Git не было что ли?SourceSafe?
> но в обычном Git операция clone репозитория в 270 Гб на любом системе будет часы занимать1. клонировать ВЕСЬ репозитарий бывает необходимо очень редко
2. Репы 270 гиг это маразм, они туда что, все версии венды запихали со всеми обоями и бинарными сборками? Сабмодули - нее, не слышал?
3. GVFS requires Windows 10 Anniversary Update or later - нет M$, спасибо. Сами пользуйтесь своей убогой 10кой
Смейтесь, смейтесь. Вы просто не в тренде. Сейчас все так делают, правда обычно HG втыкают вместо Git, т.к. он лучше с такими мега-репами работают. Хотя у гугла вот Perforce.Так делает гугл: http://cacm.acm.org/magazines/2016/7/204032-why-google-store...
Фейсбук (в 2013 у них была репа на 17 млн строк, а сейчас они говорят, что "примерно столько, сколько в репе windows"): https://code.facebook.com/posts/218678814984400/scaling-merc.../Твиттер также переходит или уже перешел на такой дизайн. У MS, очевидно, те же причины так делать, как и по ссылкам выше, там довольно четкие аргументы "за".
Еще можете почитать http://gregoryszorc.com/blog/2014/09/09/on-monolithic-reposi.../ и http://www.whitewashing.de/2015/04/11/monolithic_repositorie...
Вы не заставите нас ответить. Мы будем молчать и минусовать вас. Через это мы показываем, что ваше мнение нас не устраивает.
*пожимая плечами* да пожалуйста. Я тоже привык к обычным мелким репам. Но иногда наблюдать, как teamcity тратит минуту, чтобы сделать checkout кучи реп по отдельности - просто чтобы проверить, есть ли изменения грустно. Или вот из этого описанногоComponents, features, products, and teams come and go, merge and split. The only constant is change. And if you are maintaining separate repositories that attempt to map to this ever-changing organizational topology, you are going to have a bad time. Either you'll be constantly copying, moving, merging, splitting, etc data and repositories. Or your repositories will be organized in a very non-logical and non-intuitive manner. That translates to overhead and lost productivity. I think that monolithic repositories handle the realities of large organizations much better. Big change or reorganization you want to reflect? You can make a single, atomic, history-preserving commit to move things around. I think that's much more manageable, especially when you consider the difficulty and annoyance of history-preserving changes across repositories.
был потрачен далеко не один человеко-день на вот это самое "copying, moving, merging, splitting, etc data and repositories" - и это в относительно малой организации. Ах да, "Or your repositories will be organized in a very non-logical and non-intuitive manner" тоже копится и вызывает кучу проблем, пока через какое-то время их не накопится столько, что терпение лопается и тратится много часов на те самые "copying, moving, merging, splitting, etc" (где самое большое, конечно, etc - чтобы знать, что нигде ничего не сломалось). А уж "удовольствие" работать, когда в последней dev-ветке это уже сделано, а продакшен-ветки еще работают на старом разбиении реп (и это может продолжаться неделями или месяцами), а фичи мержить туда нужно... ммм... просто неописуемо.
> Вы просто не в тренде. Сейчас все так делают, правда обычно HG втыкают вместо Git, т.к. он лучше с такими мега-репами работают.Нет, HG лучше не работает даже со своими костылями. В таких помойках используют svn, perforce и свои самописные аналоги этих двух VCS (например, тот же гугл).
C HG сношается на такой большой помойке пока что только в основном FB.
И, кстати, на помойки не переходят, они обычно образуются с самого начала зарождения компании, стихийным образом. Из-за этого потом возникают проблемы при миграции с ~svn на что-то больее вменяемое для разработки ПО.
Ну, насчёт "сейчас все так делают".Из статьи про Гугл:
Google chose the monolithic-source-management strategy in 1999 when the existing Google codebase was migrated from CVS to Perforce.Early Google engineers maintained that a single repository was strictly better...
Вполне стандартная ситуация, когда никому не хочется разгребать и огребать за ошибки при переходе на другую схему работы.
270 гигабайт исходников?
У них исходнки в формате ворд что-ли?
>3,5 миллиона файловэто примерно 80кб на файл, если предположить что все файлы это исходники (что естественно не так, ибо там хренова туча бин файлов).
> GVFS позволяет Git думать, что все файлы в репозитории находятся на месте, но физически их содержимое загружается только при первом открытии.Похоже на замазывание, а не "решение". Для характерных задач, требующих доступ ко всему репозиторию (сборка системы, поиск по исходникам, ...) всё равно надо прокачать всё; а если не надо "прокачать всё", то модульность даст куда лучшие результаты.
https://github.com/Microsoft/GVFS/issues/9
> The software may collect information about you and your use of the software and send that to Microsoft.Интересно, в Microsoft хотя бы hello world без "телеметрии" сделать могут?
Все бы ничего да только лицензия такая что, "ты играйся, но если вдруг что то серьезное, то мы подумаем разрешить или нет"
Хоть новость и про костыль мелкософта, но сразу можно понять, что они ни черта не разбираются в кишках венды или она настолько завермишелена, что невозможно разделить этот хлам на модули. Вот почему все их сетапы стали измеряться гигабайтами - да потому что проще запаковать пол-венды в сетап солитёра, чем разбираться что там можно обновить, а чего не касаться.
> Исходный код проекта опубликован на Github под лицензией MIT ... дополнительно прилагается соглашение EULA, разрешающее применение только для внутреннего использования и требующее получения явного разрешения от Microsoft при использовании кода в своих продуктахлол
>> Исходный код проекта опубликован на Github под лицензией MIT ... дополнительно прилагается соглашение EULA, разрешающее применение только для внутреннего использования и требующее получения явного разрешения от Microsoft при использовании кода в своих продуктах
> лолПогоди смеяться, "набери побольше воздуха"цМНЗадорнов, Михаил в #138 настоящий Угар подогнал:
* We can't touch Source Depot, so let's hack together SDX!
* We can't touch SDX, so let's pretend for four releases that we're moving to TFS while not actually changing anything!
* Oh god, the NTFS code is a purple opium-fueled Victorian horror novel that uses global recursive locks and SEH for flow control. Let's write ReFs instead. (And hey, let's start by copying and pasting the NTFS source code and [,,,]Практически объясняет "дизигн" САБЖ-а. "Так! Мне всё ясно."//
>> лол
> Погоди смеяться, "набери побольше воздуха"цМНЗадорнов, Михаил в #138 настоящий Угар подогнал:
> * We can't touch Source Depot, so let's hack together ---
> Практически объясняет "дизигн" САБЖ-а. "Так! Мне всё ясно."//Ах, Автор решил оправдаться---> и ему хочется верить, "things for leving".
:>> This is just grumbling. I didn't appreciate the appetite people outside Microsoft have for Kremlinology. [,,,] First, I want to clarify that much of what I wrote is tongue-in-cheek and over the top
Kremlinology https://ru.wikipedia.org/wiki/%D0%A1%D0%...
:>> (Besides: you guys have systemd, which if I'm going to treat it the same way I treated NTFS, is an all-devouring octopus monster about crawl out of the sea and eat Tokyo and spit it out as a giant binary logfile.)
:>> NTFS [,,,] is very solid and well tested. The people who maintain it are some of the most talented and experienced I know.
:>> Windows and Microsoft still have plenty of technical talent. [,,,] , I want to stress that we are not insane and we are not dysfunctional. [,,,] What's indisputable fact is that our engineering division regularly runs and releases dependable, useful software that runs all over the world.
Это уже не git. Это что то новое на базе git. Самая главная идея git, имеем множество корректных репозитариев у большенства разработчиков, нарушена.
>множество корректныхЗнатно на 0 поделил. Обычно там, где "множество" - ад, изврат и содомия. Чем больше число репозитариев - тем быстрее они превращаются в бардак.
У вас взаимоисключающие предложения.
То "на 0 поделил", то "обычно"> Обычно там, где "множество" - ад, изврат и содомия. Чем больше число репозитариев - тем быстрее они превращаются в бардак.
Об этом и речь. Сваленные в одну кучу множество репозиториев - это бардак.
И не "тем быстрее они превращаются в бардак", а "сразу бардак".
> Чем больше число репозитариев - тем быстрее они превращаются в бардак.Если это более-менее копии (сравните с бэкапами различного срока свежести -- да-да, я помню про осетрину, с данными бывает и иначе), то вовсе не обязательно.
Хотя не исключено, что не поняли и спорите с собой...
Занято уже название! Через GVFS Гном монтирует и размонтирует диски. GVFS работает в связке с GIO и udisks2, а раньше был Gnome-VFS, который работал в связке с HAL.
> Занято уже название! Через GVFS ГномMS RMS видел? А он есть. Гусары, молчать про MS CAL.
> Исходный код проекта опубликован на Github (https://github.com/Microsoft/gvfs) под лицензией
> MIT." The idea of Opensource was to break free off propriertary software. Break free off this pay-to-play. And instead, she writes [Ashe Dryden - A.M.], we'he bended up in this scenario where we're now paying for the development of software that large companies finantially benefit from with little cost to them. We've somehow built this system where, yes, Opensouce ""won"" in the sense that every company is an opensource company now. I mean that Microsoft is opensourcing .NET like how mach more do you need an example of a.. of a.. of a.. yuo know... of a.. of a.. of an example do you need to show that sort of in this opensource vs propriertory battle we've won. But we've "won" it had such a cost. The cost now is that thousands of people donating money to Miscrosoft. And to Oracle. And to Apple. And to Google. Like... thats wierd! Would you write a check to Google? So why are you working on open-source for them? Very strange. " --https://www.youtube.com/watch?v=EqcuzSwySR4