The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск распределённой системы управления версиями Mercurial 4.1

06.02.2017 11:21

Доступен релиз распределённой системы управления версиями Mercurial 4.1. Код Mercurial написан на языке Python (требующие высокой производительности части оформлены в виде модулей на Си) и распространяется под лицензией GPLv2+. Среди проектов, использующих Mercurial, можно выделить следующие: Mozilla, OpenOffice.org, OpenSolaris, NetBeans, OpenJDK, Nginx, Xine и W3C.

Основные изменения:

  • Представлен новый расширяемый API для подключения движков сжатия данных, позволяющий создавать расширения с поддержкой новых форматов сжатия;
  • В основной состав включен новый движок сжатия zstd, который собирается и используется по умолчанию во многих командах при работе поверх HTTP, если клиент и сервер поддерживают данный движок. Использование zstd позволяет на 60% снизить нагрузку на CPU на стороне сервера при выполнении операций, подобных "hg bundle".
  • По умолчанию для опции "--profile" задействована новая статистическая система профилирвания, снижающая накладные расходы и выдающая более точные результаты, чем встроенный в Python профилировщик cProfile;
  • Добавлена экспериментальная поддержка дополнительных возможностей из git-diff;
  • Реализована экспериментальная команда "hg debugupgraderepo", позволяющая на месте обновить репозиторий до самой свежей версии формата хранилища;
  • Значительно увеличена производительность чтения отдельных записей revlog, что положительно сказалось на скорости сканирования изменений в больших репозиториях;
  • В два раза ускорена работа алгоритма определения различий содержимого, что привело к ускорению выполнения операций записи в репозиторий, таких как "hg commit".


  1. Главная ссылка к новости (https://www.mercurial-scm.org/...)
  2. OpenNews: Выпуск распределённой системы управления версиями Mercurial 4.0
  3. OpenNews: Facebook работает над реализацией сервера Mercurial на языке Rust
  4. OpenNews: Релиз распределённой системы управления версиями Mercurial 3.9
  5. OpenNews: Создатель системы управления версиями Mercurial передаёт проект в руки сообщества
  6. OpenNews: В Git и Mercurial устранена критическая уязвимость, проявляющаяся в Windows и OS X
Лицензия: CC-BY
Тип: Программы
Ключевые слова: mercurial, cvs
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (70) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (-), 11:47, 06/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Код Mercurial написан на языке Python (требующие высокой производительности части оформлены в виде модулей на Си)

    читеры.

     
     
  • 2.54, Андрей (??), 22:56, 07/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    До numpy им ещё очень далеко. Вот где настоящее читерство.
     
  • 2.58, Andrey Mitrofanov (?), 10:22, 08/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> Код Mercurial написан на языке Python (требующие высокой производительности части оформлены в виде модулей на Си)
    > читеры.

    Питон не тормозит. Же. https://www.mercurial-scm.org/wiki/PyPyPlan

     
     
  • 3.62, develop7 (ok), 23:35, 08/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Питон не тормозит. Же. https://www.mercurial-scm.org/wiki/PyPyPlan

    Флопсов и RAM не бывает слишком много, но бывает достаточно.

     

  • 1.2, Штунц (?), 11:49, 06/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    что меня приятно поразило в Mercurial, так это возможность посмотреть что там в репозитории ДО pull'a. Мне этого иногда в git'e не хватает
     
     
  • 2.3, Аноним (-), 11:54, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +7 +/
    А чем git fetch не угодил?
     
  • 2.4, Человектапок (?), 11:54, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    А разве git fetch -- это не оно?
     
     
  • 3.7, Аноним (-), 12:14, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, не оно. Но отчасти заменит.
     
     
  • 4.9, Аноним (-), 12:21, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Дык а в чём проблема? 'git fetch'-нул и сравнивай себе спокойно 'git diff mybranch..origin/mybranch'. ТС говорит о предпросмотре изменений -- для того, чтобы что-то посмотреть, это надо сначала стянуть (fetch) и потом сравнить (diff). Всё логично, по мне.
     
     
  • 5.19, Аноним (-), 14:39, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Тут остается телепатировать, что имелось ввиду в оригинале. Я подумал, что он про hg incoming
     
  • 5.21, Аноним (-), 14:59, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Лучше log, а не diff.

    нужно так: git fetch; git log mybranch..origin/mybranch

    В отличии от hg, в гите git log ..orgin/branch - намного функциональнее, и помогает в куче других случаев, как то при подготовке к мержу, ребейзу .

     
  • 4.34, XXXasd (ok), 16:07, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > > А разве git fetch -- это не оно?
    > Нет, не оно.

    не ври!

    git push
    git fetch
    git merge

    это ровно оно!

    а ещё вот тебе парочка комманд на изучение:

    git pull --ff-only
    и
    git pull --rebase

     
  • 2.22, Аноним (-), 15:01, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > что меня приятно поразило в Mercurial, так это возможность посмотреть что там
    > в репозитории ДО pull'a. Мне этого иногда в git'e не хватает

    pull вообще инвазивная слишком команда, надо избегать.

    то что ты написал, делается git fetch; git log ..origin/mybranch . И этот подход более общий, ты можешь сделать git log ..vasya_github/mybranch или git log ..microsoftvcs/mybranch-fix-by-Nadella

     

  • 1.5, Аноним (-), 12:05, 06/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Давайте разведём ветку конструктивного холиср0ча между сабжем и его основным конкурентом. Просто хочется знать о каких либо преимуществах одного над другим, пусть даже о мелких.
     
     
  • 2.6, Аноним (-), 12:09, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Неистово плюсую. Самому мне всё равно лениво искать профиты меркуриала в сравнении с гитом. Поэтому я громогласно заявляю -- МЕРКУРИАЛ НЕНУЖОН (и жду фанбоев, которые меня переубеждать сейчас начнут).
     
     
  • 3.8, Аноним (-), 12:18, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Поддерживаю. Даже если бы у него и были какие-то плюсы, сообщество выбрало git.
     
     
  • 4.15, Аноним (-), 13:31, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Поддерживаю. Даже если бы у него и были какие-то плюсы, сообщество выбрало
    > git.

    Не только сообщества разрабатывают софт.

     
  • 4.28, Cykooz (ok), 15:38, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Сообщество не "выбирало", оно как стадо подсело на то что дали в красивой обёртке.
    Тут просто сработало то, что гит "раскрутили" быстрее: запили довольно удобный Github, ядро линуха лежит в гите и др.
    И почему то мало кто при этом смотрел на объективные вещи: удобство использования, понятные команды, кривая обучения, работа под разными операционками (оригинальный git долгое время вообще не работал под Windows).
    И все эти холивары Git vs Mercurial продолжаются потому, что нет среди них однозначного победителя по всем пунктам. Git раскрученный и много разработчиков его знает, есть популярный Github. Но зато Mercurial более удобный, расширяемый, и по моему имеет даже больше возможностей чем Git.
     
     
  • 5.32, Аноним (-), 16:00, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Спасибо, выразили все мои мысли разом.
     
  • 5.36, XXXasd (ok), 16:14, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > оригинальный git долгое время вообще не работал под Windows

    и кому от этого было плохо? тем кто пишет под Windows? и что из этого? сами виноваты (насильно писать под Windows их не заставляли -- и работу тоже могли себе найти любую другой :))

    > И все эти холивары Git vs Mercurial продолжаются потому, что нет среди них однозначного победителя по всем пунктам

    нет. однозначный победитель есть..

    а холивары продолжаются только лишь благодаря тому что одним людям бывает скучновато (пользователям git). а другим людям не хватает мозгов понять что нужно один раз выучить git и больше не страдать хернёй. выучить по нормальному, а не слегка!

    > Но зато Mercurial более удобный

    нет. не более удобный. удобный только для тех кто привык к Mercurial (а для того кто привык к SVN -- кажется что и SVN удобнее)

    > расширяемый

    расширяемость ради расширяемости -- не нужна. git делает своё дело хорошо (и да -- расширения для него тоже есть -- хоть и бесполезные по больей части)

    > и по моему имеет даже больше возможностей чем Git

    только не известно каких.. да? :-)

     
     
  • 6.43, Cykooz (ok), 18:51, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > тем кто пишет под Windows? и что из этого? сами виноваты

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

    Линус, когда пилил Git, явно не планировал делать его решением подходящим для всех. Просто Linux-у для хранения исходников ядра запретили использовать на халяву платное решение (BitKeeper). Вот Линус и запилил Git на коленке, из кучи разных утилит и языков программирования. При этом он пилил не VCS, а систему управления базой данных VCS (чем по сути и является Git). Т.е. git сам по себе - это довольно низкоуровневая штука (что не удивительно, ведь Линус, как разработчик ядра, имеет хороший опыт создания низкоуровневых систем). Предполагалось, что поверх git-а будут создавать отдельные фронтенды, и несколько специализированных даже было создано. Но как то всё пошло не так, и git получил распространение в том виде, в каком он есть - с кучек низкоуровневых, не простых и опасных операций, с не очень адекватным для целей простого программиста CLI.

    С другой стороны есть Mercurial, который изначально разрабатывался с идей об его удобном и простом использовании именно как VCS, с которой непосредственно будут работать пользователи без всяких дополнительных фронтендов. Поэтому у них и более адекватный и простой в изучении CLI.

     
     
  • 7.46, XXXasd (ok), 20:41, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Можно подумать, что весь мир вертится вокруг линукса, а Windows и разработчики использующие его - это маргиналы, на которых не стоит обращать внимание.

    всё верно: весь прогрессивный мир крутится вокруг Linux, BSD, и open source систем..

    можете даже посмотреть на статистику "1% пользователей Linux" -- и подумать кто именно находится в 99% , а кто находится в остальных 1%.

    прикладные разработчики-под-Windows -- не мергиналы разумеется -- а просто нейтральный БИОМАТЕРИАЛ. почти ни какого эффекта на прогресс-и-развите-технологий они совершенно не оказывают.

    какой смысл обращать внимание на разработчиков-под-Windows -- совершенно не ясно. отдачи почти ни какой нет

    > Какое то у вас детское суждение.

    а у вас смотрю суждение -- статное и взрослое. ага! как же!

    просто пытетесь оправдать свою трату времени, вот и всё

     
  • 5.76, Аноним (-), 08:43, 10/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Все проще Git сделан программистами для программистов, для отследивания версий,... текст свёрнут, показать
     
  • 3.14, Аноним (-), 13:30, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Для сообщества лучше гит.

    Для корпораций - в некоторых аспектах меркуриал.

     
     
  • 4.16, Я (??), 13:50, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Тупняк какой-то. Выбирают конкретные разработчики, а не "сообщество" или "корпорации". Если мне удобен меркуриал, то мне он удобен независимо от того, для кого я делаю проект. И так же с гитом.
     
     
  • 5.17, Аноним (-), 14:11, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    я так понимаю, все зависит от процессов, которые workflow

    т.е. в разных ситуациях одному и тому же разработчику может быть более удобен то git, то mercurial.

    просто в в обычном opensource, который строится на сообществе - более удобен git. но при работе в некоторых компаниях mercurial может оказаться более подходящим решением. повторюсь, всё это справедливо даже для одного и того же разработчика.

     
     
  • 6.24, Аноним (-), 15:08, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И какие же, прости госспади, волшебные workflow  меркуриал поддерживает?

    http://nvie.com/posts/a-successful-git-branching-model/ можно и нужно применять хоть в гите, хоть в hg. Но hg не нужен, да. Пока не доказано обратное, ибо зачем плодить сущности.

     
     
  • 7.31, Alexey (??), 15:55, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тыщи дистрибутивов линукса значит нужны, а меркуриал не нужен.
     
  • 7.42, fi (ok), 17:43, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Приходишь так в сообщество, смотришь а там… у всех меркуриал  - и ты им так: «Всё парни, с завтрашнего дня только git, я сказал!» :)

    зы. был тут у нас один гитовец, ничего, перековали на svn :D :D :D  

     
     
  • 8.52, Аноним (-), 12:08, 07/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Что-то у тебя ответ не связан с вопросом В огороде бузина В компании можете ... текст свёрнут, показать
     
  • 8.55, Андрей (??), 23:01, 07/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А на самом деле наоборот кто-то разрабатывает себе в меркуриал Вот начинают пр... текст свёрнут, показать
     
     
  • 9.56, Cykooz (ok), 23:10, 07/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот и пускай проходят себе мимо Если они не в состоянии осилить меркуриал хотя ... текст свёрнут, показать
     
     
  • 10.77, Аноним (-), 08:53, 10/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Что характерно, именно это обычно и происходит Вот прямо идешь в новость и смот... текст свёрнут, показать
     
  • 3.49, бедный буратино (ok), 02:47, 07/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > и жду фанбоев, которые меня переубеждать сейчас начнут

    сообществу пофиг. сообщество юзает и то, и то.

    мне тоже пофиг. я тоже юзаю и то, и то, и выбирать что-то одно и клеить его на флаг - не собираюсь

     
     
  • 4.51, Аноним (-), 10:14, 07/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Поддерживаю.
     
  • 2.23, Аноним (-), 15:05, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В hg нет веток. На этом можно и закончить. То, что там называю ветками, это какая-то хня.

    Но я не закончу. В changeset в меркуриале попадает название "ветки". Т.е. буквально: "default" или "myC00lBran4". Это потом всплывает при мерже в репозитарий, где ветки "myC00lBran4" нет.

    Хватит?

     
     
  • 3.26, Аноним (-), 15:12, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Разупорись, будь добр
     
     
  • 4.27, Аноним (-), 15:25, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    По существу будет аргументация? Или "нам наплевать на кривость и косяки, лишь бы гламурный TortoiseHg под десяточкой запускать, а не непонятную консоль в гите"
     
     
  • 5.33, Аноним (-), 16:00, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кратко:
    1) В меркуриал таки ветки, в git - указатели. Это по большому счету, вопрос терминологии.
    2) В меркуриал как раз таки ветки "есть везде". 3) То, что в changeset  есть название ветки, кому-то даже удобней

    То, что в Mercurial превыкли называть веткой - это heavybranch. А бошки, что в гите, что в меркуриал.
    Ну, и первый гугл: https://www.mercurial-scm.org/wiki/GitConcepts

     
     
  • 6.39, Аноним (-), 16:37, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >1

    согласен, это вопрос терминологии. Для меня ветки hg не узабельны, в том числе и из-за п.2

    >2

    Неиллюзорные проблемы мержа в свою репу я испытываю в hg. Дело касается реально больших изменений, когда в стороннем репе используются свои ветки. Поэтому мне это не удобно, да

     
  • 3.30, Cykooz (ok), 15:55, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В hg нет веток.

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

     
     
  • 4.70, anonymous (??), 23:32, 09/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> В hg нет веток.
    > Вы это о чём? Вот как раз в гите нет настоящих веток,
    > то что там называется веткой - это просто локальная именованная ссылка
    > на один из top-овых коммитов в дереве, которая не пушится во
    > внешнюю репу.
    > В меркуриале есть аналог таких вот именованных ссылок, и они тоже работают
    > только в локальном репазитории и не уходят во внешние репы.

    Вы зря мешаете тёплое с мягким. Именованная ссылка --- это одно. Передача именнованных ссылок в другой репозиторий --- это другое. А branch --- это узел в графе коммитов у которого два потомка. И в hg это, наверное, должно быть так же.

     
     
  • 5.72, Cykooz (ok), 23:41, 09/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > А branch ---
    > это узел в графе коммитов у которого два потомка. И в
    > hg это, наверное, должно быть так же.

    Хм, branch - это так то ветка, а не узел (node), поэтому ваше определение как то не очень подходит.

     
     
  • 6.73, anonymous (??), 23:59, 09/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Хм, branch - это так то ветка, а не узел (node), поэтому ваше определение как то не очень подходит.

    Хорошо. Любой путь к листу в графе коммитов. А узел в графе коммитов у которого два потомка --- это branch point. Так лучше?

     
  • 3.48, gaga (ok), 00:18, 07/02/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Т.е. даже первую страницу самого простого туториала по ртути ты прочитать не осилил дальше заголовка? Потому что там обычно во втором абзаце написано, что то, что в гите называется ветками, в меркуриал называется букмарк, что намного правильней.
     
     
  • 4.53, Аноним (-), 12:10, 07/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты так говоришь, как будто этими букмарками пользовался. Или теоретик-читатель мануалов? Простите, но букмарки это инородно даже hg, и неюзабельно соответственно. И это совсем не то, что ветки в гите, а "аналог". Китайский, ага
     
  • 2.29, Crazy Alex (ok), 15:48, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Различия не настолько принципиальны, чтобы быть причиной выбора, поэтому проще взять то, что более распространено - то есть гит.
     
  • 2.44, develop7 (ok), 19:26, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Pro Mercurial

    * Rename/copy tracking
    * Phases (мешает переписать опубликованную историю)
    * ChangesetEvolution (что-то вроде распределённого reflogа).
    * Revsets
    * Продуманные UI и руководство
    * Extensions на любой вкус (hggit, hgsubversion, largefiles, тысячи их)
    * Graft (аналог cherrypick) пишет id предка в метаданные, а merge его учитывает

    Pro Git

    * Octopus merge
    * Staging area (я не пользуюсь)
    * rerere (говорят, полезно, не пользовался)

     
     
  • 3.63, Andrey Mitrofanov (?), 09:20, 09/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Pro Mercurial
    > * Продуманные UI и руководство
    > Pro Git
    > * Staging area (я не пользуюсь)

    ''Git has something called the "staging area" or "index".''

    :-O   Матёро!

     
     
  • 4.64, develop7 (ok), 16:37, 09/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > ''Git has something called the "staging area" or "index".''
    > :-O   Матёро!

    што

     
     
  • 5.66, Andrey Mitrofanov (?), 16:42, 09/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    #>> Pro Git
    #>> * Staging area (я не пользуюсь)
    >> ''Git has something called the "staging area" or "index".''
    >> :-O   Матёро!
    > што

    Не пользоваться индексом *и* пользоваться git-ом -- это авангардненько-артхаусненько, это не для слабаков, это надо очень напрячься, чтоб суметь. Мастер[I]![/I]

     
     
  • 6.68, develop7 (ok), 19:25, 09/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Не пользоваться индексом *и* пользоваться git-ом -- это авангардненько-артхаусненько, это не для слабаков, это надо очень напрячься, чтоб суметь. Мастер[I]![/I]

    Я понимаю, что там где-то под капотом IDEA, возможно, и вызывает git-add, но сам я — нет, т.к. незачем. А коль понадобится раз в полгода закоммитить правки в файле через одну, ну, скомандую git commit --patch, делов-то. Ну то есть понятно, что диды с торвольцом завещали сначала добавлять правки в индекс, потом коммититься и всё такое, но с каких пор подумать своей головой стало ракетной наукой?

     

  • 1.18, Аноним (-), 14:25, 06/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Есть репозиторий на Mercurial, в котором по какому-то стечению обстоятельств создалась вторая "головная" ветвь в бранче default, состоящая из одного коммита. В битбакете оно светится как "main branch (2 heads)". Теперь это дело мешает жить, правки из этого коммита уже не актуальны (соответственно вмержить в основную ветвь их нельзя), но и удалить этот второй мастер не получается.

    >> hg strip -r

    удаляет локально лишний коммит и его бранч, но при pull он стягивается с сервера повторно

    >> hg backout -r

    abort: cannot backout change that is not an ancestor

     
     
  • 2.20, Аноним (-), 14:41, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Анон, вмёрж его и сделай revert но его номеру, не мучайся
     
  • 2.45, develop7 (ok), 19:29, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Стрипните лишнюю голову в вебморде bitbucket
     

  • 1.25, DmA (??), 15:09, 06/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    вот бы на этой коммерческой системе запустить репозиторий винды в 250 гб и 3,5 млн файлов.
     
     
  • 2.35, Аноним (-), 16:11, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно, интересно. Но тут, мне кажется, проблема не в системе контроля версий, а "что-то в этой репе не так".
     
  • 2.37, Cykooz (ok), 16:28, 06/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну можно в качестве примера взять опыт Facebook, у них конечно не 250Гб наверное (3 года назад в git копии у них было 54Гб) - https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ . Они решили свои проблемы со скоростью как то более правильно - сделали какие то патчи для меркуриал, написали расширение для него специальное, которое вероятно теперь доступно для всех.
    Майкрософт же приняло решение не трогать "бяку", и навертеть оптимизаций сбоку от Git-а. Запилили виртуальную FS-ку, и изменили серверную версию Git, что бы она поддерживала эту FS. В результате их решение работает только у них.
     

  • 1.47, Аноним (-), 23:19, 06/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    всем кто спеной у рта доказывает что гит ваше/наше все а ртуть *авн0 и считает что в в голове у вас опилки^Wсерое вещество вот вам немного чтения как пример того что может "гогно"

    https://groups.google.com/forum/#!topic/mozilla.dev.version-control/nh4fITFlEMk

    а еще погуглите столько времени занимает git diff в склонированой репке ядра

     
  • 1.57, Аноним228 (?), 05:46, 08/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Xine 5 лет как закрылся, нарколыги!
     
     
  • 2.59, Andrey Mitrofanov (?), 10:27, 08/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Xine 5 лет как закрылся, нарколыги!

    --Св-----, они убили xine. Опять.

     
  • 2.60, Аноним (-), 17:42, 08/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как закрылся?
     

  • 1.61, Вареник (?), 18:54, 08/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Лучшая Version Control System.

    Bazaar гибче, Mercurial продуманней.

     
     
  • 2.78, Аноним (-), 08:57, 10/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Bazaar гибче, Mercurial продуманней.

    А git еще и работает к тому же. Не тормозит. И сделан для програмеров а не гламурных тупиц в десятке.

     

  • 1.65, Аноним (-), 16:37, 09/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вопрос знатокам hg: зачем в практике сопровождения hg-based-проектов частенько рвут историю на разные репозитории?

    Приблизительно как здесь:
    https://gmplib.org/repo/
    (gmp, gmp-???, ... )

     
     
  • 2.67, Cykooz (ok), 18:50, 09/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вопрос знатокам hg: зачем в практике сопровождения hg-based-проектов частенько рвут историю
    > на разные репозитории?

    Может как раз таким образом решают проблему больших репазиториев? Если они не делают бакпорт фиксов и каких то фичей в старые версии, то нет какого то особого резона тащить хвост из коммитов от старой версии, если их там 100500 и занимают дофига места. Тоже самое можно делать и на Git - это не какая то особенность присущая меркруиал репазиториям.


     
     
  • 3.69, anonymous (??), 23:22, 09/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Может как раз таким образом решают проблему больших репазиториев?

    В это не верится: история не обрезается снизу (старая), а подрезается сверху; экономии места нет, даже наоборот --- у бОльших репозиториев возможность переиспользовать идентичные блоки выше. Какие-то пляски с долгоподдерживаемыми ветками (как-бы-ветками?)? Но зачем? Хрень какая-то --- проблемы вижу, рационального зерна не вижу.

     
     
  • 4.71, Cykooz (ok), 23:34, 09/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > В это не верится: история не обрезается снизу (старая), а подрезается сверху;

    Ну тогда фиг знает, это видимо какая то непонятная задумка авторов этой либы. Я сам такого нигде не встречал ещё.

     
     
  • 5.74, anonymous (??), 00:03, 10/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> В это не верится: история не обрезается снизу (старая), а подрезается сверху;
    > Ну тогда фиг знает, это видимо какая то непонятная задумка авторов этой
    > либы. Я сам такого нигде не встречал ещё.

    А это не специфично для gmp. Но в hg-репозиториях я такое несколько раз встречал.

    Ладно, отнесем к разряду "какая-то хрень".

     
     
  • 6.75, Cykooz (ok), 00:34, 10/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > А это не специфично для gmp. Но в hg-репозиториях я такое несколько
    > раз встречал.
    > Ладно, отнесем к разряду "какая-то хрень".

    Как вариант - это просто один и тот же реп, склонированный на сервере в разные папки и переключенный на соответствующие бранчи, что бы можно было с ними параллельно работать. Никакого доп. места на диске для хранения истории оно не занимает, т.к. она "клонируется" как хард-линка. Точно так же можно сделать и локально, если нужно параллельно работать с разными бранчами.
    Хотя в случае GMP смущает что набор тегов в этих "репах" всё таки отличается.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру