LINUX.ORG.RU
ФорумTalks

Facebook пишет свой Mercurial сервер на Rust

 ,


1

4

Собственно, сабж!

Фейсбук пишет свой сервер Mercurial на расте: https://groups.google.com/forum/m/#!topic/mozilla.dev.version-control/nh4fITF...

* Facebook is writing a Mercurial server in Rust. It will be distributed and will support pluggable key-value stores for storage (meaning that we could move hg.mozilla.org to be backed by Amazon S3 or some such). The primary author also has aspirations for supporting the Git wire protocol on the server and enabling sub-directories to be `git clone`d independently of a large repo. This means you could use Mercurial to back your monorepo while still providing the illusion of multiple «sub-repos» to Mercurial or Git clients. The author is also interested in things like GraphQL to query repo data. Facebook engineers are crazy... in a good way.

★★★★★

Круто-круто. Опенсорс?

Stil ★★★★★ ()

It looks like official support forPython 3 support will happen sometime in 2017.

Вот это покруче новость.

Kilte ★★★★★ ()
Последнее исправление: Kilte (всего исправлений: 1 )

react, bower, graphQL, yarn, теперь это.

Тот случай когда открытие исходников вредит сообществу нежели приносит пользу

makoven ★★★★★ ()
Последнее исправление: makoven (всего исправлений: 1 )
Ответ на: комментарий от Harald

Когда гит начнет хоть както уметь ворочать отдельными директориями, тогда от него будет какая то польза... а пока народ сливает гиговые репы ради одного файлика и радостно жрет что ему дают, аргументируя что «сам Линус его использует»

WindowsXP ★★ ()
Ответ на: комментарий от Gvidon

> will support pluggable key-value stores for storage
Но зачем?

Чтобы можно было организовать центральное хранилище без обязательной многоэтажной свалки мелких файлов. Это даст возможность хранить репу внутри облачных БД или на сетевых ФС, например.

shahid ★★★★★ ()
Ответ на: комментарий от Deleted

И что? Это очередной костыль, все равно сливается вся репа... сравни .git размер и объем скаченого на полном clone и на sparse checkout...

WindowsXP ★★ ()
Ответ на: комментарий от WindowsXP

как только придет осмысление, как устроет distributed, то сразу отпустит. если уж сильно подгорает, то можно так:

git archive --format=tar --remote=git://git.foo.com/project.git HEAD:path/to/directory filename | tar -O -xf -
Deleted ()
Ответ на: комментарий от Deleted

как только придет осмысление, как устроет distributed

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

WindowsXP ★★ ()
Ответ на: комментарий от WindowsXP

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

Мб может проще Git зопатчить, чем опять все ломать? Серьезно, каждый раз начинается «давайте нахрем сломаем все и в этот-то раз сделаем нормально». В итоге как только все более-менее утряслось вылезает новый упырь и поехало.

kirk_johnson ★☆ ()
Ответ на: комментарий от tailgunner

«enabling sub-directories to be `git clone`d independently of a large repo. This means you could use Mercurial to back your monorepo while still providing the illusion of multiple «sub-repos» to Mercurial or Git clients» както так пишут...

WindowsXP ★★ ()
Ответ на: комментарий от kirk_johnson

Мб может проще Git зопатчить

Зачем патчить ущербное? к тому же там проблема в дизайне и структуре хранения данных репы...

WindowsXP ★★ ()
Ответ на: комментарий от WindowsXP

Зачем патчить ущербное? к тому же там проблема в дизайне и структуре хранения данных репы...

Вот-вот. И так каждый раз.

kirk_johnson ★☆ ()
Ответ на: комментарий от kirk_johnson

Мб может проще Git зопатчить, чем опять все ломать? Серьезно, каждый раз начинается «давайте нахрем сломаем все и в этот-то раз сделаем нормально».

Вот-вот. И так каждый раз.

Иногда полезно всё сломать и начать заново.

X.Org, к примеру, так и не могут «запатчить» из-за общей сложности кодовой базы и упоротости X.org-разработчиков, которые сами не понимают как у них там работают отдельные подсистемы. Потому всё ломают, выбрасывают на помойку и делают Wayland, Mir, Freon и прочее.

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

Ещё он не поддерживает добавления в себя пустых директорий. Добавлять туда файлики .blank — жуткий костыль. А создать предварительную структуру каталогов на этапе планирования и проектирования проекта бывает очень важным.

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 2 )
Ответ на: комментарий от EXL

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

И это, конечно же, очень сложно поправить запатчив Git.

Ещё он не поддерживает добавления в себя пустых директорий. Добавлять туда файлики .blank — жуткий костыль. А создать предварительную структуру каталогов на этапе планирования и проектирования проекта бывает очень важным.

Пфф.

kirk_johnson ★☆ ()
Ответ на: комментарий от EXL

Не видел таких патчей на Git. Не подскажешь где взять?

Я тоже не видел. Потому что их никто не написал.

kirk_johnson ★☆ ()
Ответ на: комментарий от kirk_johnson

И это, конечно же, очень сложно поправить запатчив Git.

с учетом того как он передает данные - не слишком просто.. если только сваливать на сервере предварительно сохраненные архивы.. которые весят больше чем вся репа в разы

WindowsXP ★★ ()
Ответ на: комментарий от WindowsXP

с учетом того как он передает данные - не слишком просто.. если только сваливать на сервере предварительно сохраненные архивы.. которые весят больше чем вся репа в разы

Или поменять метод передачи данных :)

kirk_johnson ★☆ ()
Ответ на: комментарий от kirk_johnson

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

И это, конечно же, очень сложно поправить запатчив Git.

Это не запатчили за 11 лет. Вероятно, это не так уж просто (а если подумать над моделью хранения Git - в общем случае тупо невозможно).

tailgunner ★★★★★ ()
Ответ на: комментарий от WindowsXP

enabling sub-directories to be `git clone`d independently of a large repo. This means you could use Mercurial to back your monorepo while still providing the illusion of multiple «sub-repos» to Mercurial or Git clients

Это возможность объединять несколько репозиториев в один. А тебе, насколько я понял, нужно чекаутить подкаталоги большого репа, SVN-стайл.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Это не запатчили за 11 лет. Вероятно, это не так уж просто (а если подумать над моделью хранения Git - в общем случае тупо невозможно).

Там был GSoC на тему, я не особо вчитывался. Но я отказываюсь верить в то, что если буферизировать данные в буфере TCP — то все ок, а если буферизировать где-нибудь на диске — то нет.

Во, нашел: https://git.wiki.kernel.org/index.php/SoC2009Ideas

The difficulty of this task is under a dispute: it should be fairly easy to make clone restartable for (deprecated) rsync:// protocol and for «dumb» protocols using commit walker, like http://. It shouldn't be too difficult to design user interface for this feature. Adding resume support to git-clone over «smart» protocols using packfile generation like git:// and ssh:// would require (most probably) good knowledge of pack protocol and packfiles. It would require most probably new extension to git protocol.

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 1 )
Ответ на: комментарий от Harald

Я вот сегодня на 2 машинах пытался слить код с гитхаба, чтоб он сразу стал нетбинс проектом. У меня ушло где-то час. В итоге все равно все руками копировал. Потом это гогно мне не хотело пушить нормально. Говорило, что изменений нет. Я смотрю в измененный и закоммиченый файл, а оно мне говорит «no changes». Потом гордо заявило, что я вне бранча состою, а мне показывается original/master...

Я так-то особо пряморукостью не отличаюсь, но это какая-то жопь, извините.

unt1tled ★★★★ ()
Ответ на: комментарий от Harald

Я вот когда смотрю в гитхуб, делаю pull и оно говорит «already latest», а в гитхубе другой код в том же файле, мне какую документацию читать именно? При том, что бранч тот же.

unt1tled ★★★★ ()
Ответ на: комментарий от unt1tled

нужны подробности

с того ли ты гитхаба тянешь, точно ли бранчи те же и т.д.

Harald ★★★★★ ()

The primary author also has aspirations for...

Жениться тебе надо, барин.

zabbal ★★★★★ ()

Я смотрю фейспук слепо верит, что всё, что он делает - есть благо в высшей степени. Кому нужен mercurial, когда есть божественный git, дарованный человечеству солнцеликим Линусом?

ekzotech ★★★★ ()
Ответ на: комментарий от EXL

Добавлять туда файлики .blank — жуткий костыль.

Ни разу такого не видел. Видел, что люди добавляют файл PLACEHOLDER, в котором желательно объяснить зачем эта пустая директория нужна. И это не только проблема Git многим тулзам иногда нужно объяснять, что пустая директория тоже нужна.

foror ★★★★ ()
Последнее исправление: foror (всего исправлений: 1 )
Ответ на: комментарий от foror

.blank, PLACEHOLDER или DeleteMe — это не так важно.

Плохо то, что нельзя добавить директории в процессе проектирования проекта.

EXL ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.