Здравствуйте, ·, Вы писали:

V>>·>_К примеру_ можно и на сервер, но это может быть любой доступный сервер — ssh, ftp, nfs, даже smtp. Или вообще без сервера, на соседний компьютер (network drive), на флешку, и т.п., это совсем не то же, что ты утверждаешь что "у любого vcs есть ремоут сервер".
V>>Это не тоже самое, ты не сможешь, к примеру, автоматически смержиться. А если бы был сервер, то всё тоже, только с сохранением в удалённом репозитории.
·>В гите мерж _всегда_ происходит в локальном репо. Сервер-несервер вообще никак влиять на мержи не может.
Я про выделенное, оно автоматически мержить ничего не будет.

V>>А коммитить и брать удалённо ты как собрался?
·>В гите коммит _всегда_ происходит в локальном репо. Брать удалённо — так же, используя любой механизм обмена с ремотами.
Это и есть коммит/апдейт с сервером, просто называется по-другому. Но сервер всё-равно надо держать, ибо все с ним будут обмениваться в любое время.

V>>Централизация нужна вообще для всего, а не только для этого. Всё-равно есть сервер откуда все берут и куда все кладут, это неизбежно.
·>В _Distributed_ Version Control System централизация не нужна по определению. Хотя, эту централизацию можно организовать в некой окресности, если вдруг станет надо.
Я почему это не должно быть надо?

V>>Так как на счёт транзакций, сам будешь ресолвить и мержить? Кто коллизии будет разрешать, тоже git send-mail или человек?
·>Точно так же как и с обычными ветками.
С чего вдруг также, если мыло никакой транзакционностью не обладает?

V>>>>Когда народу больше становится, то абсолютно необходимо. А это как правило всегда.
V>>·>Не абсолютно и обходимо.
V>>Пример?
·>Ну, например, разберись что такое такое fork в github.
Это ничуть не пример, это тоже самое что я отдельно скопирую репу свн в отдельный каталог и буду работать с ней независимо как и с исходной. Где пример с большим количеством народу и одной историей на всех?

·>Так в чём отличия-то? Создавай приватный репо физически на другой машине, никто не запрещает, никакой специальный установленный админами "сервер git" не нужен. Например, если у тебя есть доступ к network drive, ssh куда-нибудь или тупо флешка — этого достаточно.
А чем оно лучше обычного бэкапа тогда? Точно также можно подключить и всю папку скопировать, история то локальных изменений не нужна.

V>> Это открытая инфа. Кто тебе в бложек про закрытый серв то напишет?
·>Например, кто-то будет искать инфу о том как пользоваться git-ом, неважно — закрытым сервом или у себя дома. Или кто-то напишет в бложике, что у них в BigCompany Ltd переезжают на другую vcs.
Это вообще не статистика.

·>А что по-твоему означает слово "moving"?
Так где мувинг то? Как работал репозиторий, так и работает.

Здравствуйте, Vain, Вы писали:

V>Как это не может? Я сомневаюсь что у перфорса нельзя одновременно читать из базы, да ещё в 2011 году. Может, всё-таки, кто-то лок сделал? Тогда да, там включается эксклюзивный доступ.

Читать может, работать — нtт

В каталоге тысячи artist assets (картинки, модели и т.п., в проекте несколько сотен тысяч файлов). На всем этом работают различные тулзы и они не дадут правильно работать с файлами (открыть на редактирование), которые уже checkout кто-то другой.

Здравствуйте, Vain, Вы писали:

V>>>Это не тоже самое, ты не сможешь, к примеру, автоматически смержиться. А если бы был сервер, то всё тоже, только с сохранением в удалённом репозитории.
V>·>В гите мерж _всегда_ происходит в локальном репо. Сервер-несервер вообще никак влиять на мержи не может.
V>Я про выделенное, оно автоматически мержить ничего не будет.
В гите мерж _всегда_ происходит в локальном репо, другие репы и есть ли они вообще, не важно какой к ним доступ — никакого влияния на процесс мержа не оказывают.

V>>>А коммитить и брать удалённо ты как собрался?
V>·>В гите коммит _всегда_ происходит в локальном репо. Брать удалённо — так же, используя любой механизм обмена с ремотами.
V>Это и есть коммит/апдейт с сервером, просто называется по-другому. Но сервер всё-равно надо держать, ибо все с ним будут обмениваться в любое время.
Так какой сервер-то?? Counter Strike? Ещё раз. Это децентрализованная система контроля версий.

V>>>Централизация нужна вообще для всего, а не только для этого. Всё-равно есть сервер откуда все берут и куда все кладут, это неизбежно.
V>·>В _Distributed_ Version Control System централизация не нужна по определению. Хотя, эту централизацию можно организовать в некой окресности, если вдруг станет надо.
V>Я почему это не должно быть надо?
А почему это должно быть надо?

V>>>Так как на счёт транзакций, сам будешь ресолвить и мержить? Кто коллизии будет разрешать, тоже git send-mail или человек?
V>·>Точно так же как и с обычными ветками.
V>С чего вдруг также, если мыло никакой транзакционностью не обладает?
С того. Перестань философствовать, возьми да и сам попробуй. Делов-то.

V>>>Пример?
V>·>Ну, например, разберись что такое такое fork в github.
V>Это ничуть не пример, это тоже самое что я отдельно скопирую репу свн в отдельный каталог и буду работать с ней независимо как и с исходной. Где пример с большим количеством народу и одной историей на всех?
Просто _разберись_ что такое такое fork в github. Подсказка: pull requests.

V>·>Так в чём отличия-то? Создавай приватный репо физически на другой машине, никто не запрещает, никакой специальный установленный админами "сервер git" не нужен. Например, если у тебя есть доступ к network drive, ssh куда-нибудь или тупо флешка — этого достаточно.
V>А чем оно лучше обычного бэкапа тогда? Точно также можно подключить и всю папку скопировать, история то локальных изменений не нужна.
Тем что это просто ещё один репо, с которым работаешь ровно так же как и с любым другим.

V>>> Это открытая инфа. Кто тебе в бложек про закрытый серв то напишет?
V>·>Например, кто-то будет искать инфу о том как пользоваться git-ом, неважно — закрытым сервом или у себя дома. Или кто-то напишет в бложике, что у них в BigCompany Ltd переезжают на другую vcs.
V>Это вообще не статистика.
А что по-твоему такое статистика?!

V>·>А что по-твоему означает слово "moving"?
V>Так где мувинг то? Как работал репозиторий, так и работает.
Так английский ты тоже не знаешь? Ну там "present continuous"... ничего не говорит?
Короче, приведи перевод той цитаты, даже любопытно.

Здравствуйте, Vetal_ca, Вы писали:

V_>В каталоге тысячи artist assets (картинки, модели и т.п., в проекте несколько сотен тысяч файлов). На всем этом работают различные тулзы и они не дадут правильно работать с файлами (открыть на редактирование), которые уже checkout кто-то другой.
Так там просто флажок read only убирается, не? Я помню вручную его убирал и редактировал.

Здравствуйте, Vetal_ca, Вы писали:

V>>Как это не может? Я сомневаюсь что у перфорса нельзя одновременно читать из базы, да ещё в 2011 году. Может, всё-таки, кто-то лок сделал? Тогда да, там включается эксклюзивный доступ.
V_>Читать может, работать — нtт
V_>В каталоге тысячи artist assets (картинки, модели и т.п., в проекте несколько сотен тысяч файлов). На всем этом работают различные тулзы и они не дадут правильно работать с файлами (открыть на редактирование), которые уже checkout кто-то другой.
Что-то я не понял про что ты говоришь, потому-что Perforce 2006.2 прекрасно даёт делать Open for Edit с разных компов (там красная и зелёная галки появляются, что говорит о том, что не только тобой файл начал редактироваться, что даёт возможность связаться с редактирующим файл и предварительно договориться и разграничить области редактирования до самого коммита (!) (где в гите вообще такая фишка есть???)). А при попытке закоммитить с коллизией — даёт ресолвить через мерж.
К тому же я не нашёл опции Check Out, есть опция Sync, есть опция Open for Edit/Delete, но именно Check Out — нету.

Здравствуйте, ·, Вы писали:

V>>Это и есть коммит/апдейт с сервером, просто называется по-другому. Но сервер всё-равно надо держать, ибо все с ним будут обмениваться в любое время.
·>Так какой сервер-то?? Counter Strike? Ещё раз. Это децентрализованная система контроля версий.
Ещё раз, общее место для коммита/апдейта необходимо всегда, где там децентрализация, если УЖЕ требуется общая часть-центр для обмена? Пчёлы против мёда?

V>>>>Централизация нужна вообще для всего, а не только для этого. Всё-равно есть сервер откуда все берут и куда все кладут, это неизбежно.
V>>·>В _Distributed_ Version Control System централизация не нужна по определению. Хотя, эту централизацию можно организовать в некой окресности, если вдруг станет надо.
V>>Я почему это не должно быть надо?
·>А почему это должно быть надо?
По новому кругу идём. Как ты случайному челу передашь свои изменения, будешь его сам искать и предлагать свои изменения, или передашь в общий/центральный репозиторий, где он сам возьмёт?

V>>>>Так как на счёт транзакций, сам будешь ресолвить и мержить? Кто коллизии будет разрешать, тоже git send-mail или человек?
V>>·>Точно так же как и с обычными ветками.
V>>С чего вдруг также, если мыло никакой транзакционностью не обладает?
·>С того. Перестань философствовать, возьми да и сам попробуй. Делов-то.
Зачем мне пробовать кактус?

V>>Это ничуть не пример, это тоже самое что я отдельно скопирую репу свн в отдельный каталог и буду работать с ней независимо как и с исходной. Где пример с большим количеством народу и одной историей на всех?
·>Просто _разберись_ что такое такое fork в github. Подсказка: pull requests.
И где там общая история?

V>>>> Это открытая инфа. Кто тебе в бложек про закрытый серв то напишет?
V>>·>Например, кто-то будет искать инфу о том как пользоваться git-ом, неважно — закрытым сервом или у себя дома. Или кто-то напишет в бложике, что у них в BigCompany Ltd переезжают на другую vcs.
V>>Это вообще не статистика.
·>А что по-твоему такое статистика?!
Ты читай внимательно что там измеряли, а измеряли там количество запросов по ключевым словам, т.е. в попугаях в вакууме, что ни разу не говорит о количестве серверов и статистике использования. Если народ не понимает как git использовать, он будет генерить массу запросов в гугл, что ни разу ни показатель хорошесть git, а скорее наоборот.
А статистикой будет, к примеру, количество скачиваний+установок[+удалений] или количество активных репозиториев на разных опенспейс доменах.
Вот, к примеру, статистика по Preforce Helix (крутить вниз к цифрам): https://www.perforce.com/helix

Users: 36k
Transactions/day: 47M
Megabytes: 36M

V>>·>А что по-твоему означает слово "moving"?
V>>Так где мувинг то? Как работал репозиторий, так и работает.
·>Так английский ты тоже не знаешь? Ну там "present continuous"... ничего не говорит?
·>Короче, приведи перевод той цитаты, даже любопытно.
Причем здесь перевод? Когда есть факт текущего использования? Не говори гоп пока не перепрыгнешь.

Здравствуйте, Vain, Вы писали:
V_>>В каталоге тысячи artist assets (картинки, модели и т.п., в проекте несколько сотен тысяч файлов). На всем этом работают различные тулзы и они не дадут правильно работать с файлами (открыть на редактирование), которые уже checkout кто-то другой.
V>Что-то я не понял про что ты говоришь, потому-что Perforce 2006.2 прекрасно даёт делать Open for Edit с разных компов (там красная и зелёная галки появляются, что говорит о том, что не только тобой файл начал редактироваться, что даёт возможность связаться с редактирующим файл и предварительно договориться и разграничить области редактирования до самого коммита (!) (где в гите вообще такая фишка есть???)). А при попытке закоммитить с коллизией — даёт ресолвить через мерж.
V>К тому же я не нашёл опции Check Out, есть опция Sync, есть опция Open for Edit/Delete, но именно Check Out — нету.

Я не помню точно какие опции и как. Ибо забросил в пользу git. Но проблема была и IT отдел ничего не могла сделать.

Естественно, если было бы так просто то поставили бы опцию. Но шансы, что проблема в опции а не концептуальная, исчезающе мала.

Потом добавили какой-то местный кэширующий прокси, стало немного быстрее но проблема не была решена.

Здравствуйте, Vetal_ca, Вы писали:

V_>Я не помню точно какие опции и как. Ибо забросил в пользу git. Но проблема была и IT отдел ничего не могла сделать.
V_>Естественно, если было бы так просто то поставили бы опцию. Но шансы, что проблема в опции а не концептуальная, исчезающе мала.
V_>Потом добавили какой-то местный кэширующий прокси, стало немного быстрее но проблема не была решена.
А с чего ты тогда взял что Perforce виноват а не какой-нить раутер между точками? Перфорс используют туча народу и такая проблема бы сразу была заметна всем.

Здравствуйте, Vain, Вы писали:

V>>>Это и есть коммит/апдейт с сервером, просто называется по-другому. Но сервер всё-равно надо держать, ибо все с ним будут обмениваться в любое время.
V>·>Так какой сервер-то?? Counter Strike? Ещё раз. Это децентрализованная система контроля версий.
V>Ещё раз, общее место для коммита/апдейта необходимо всегда, где там децентрализация, если УЖЕ требуется общая часть-центр для обмена? Пчёлы против мёда?
Это общее место — локальный репо.

V>>>Я почему это не должно быть надо?
V>·>А почему это должно быть надо?
V>По новому кругу идём. Как ты случайному челу передашь свои изменения, будешь его сам искать и предлагать свои изменения, или передашь в общий/центральный репозиторий, где он сам возьмёт?
Да. Или он сам возьмёт у тебя, если ты расшаришь доступ к своему репо.

V>>>С чего вдруг также, если мыло никакой транзакционностью не обладает?
V>·>С того. Перестань философствовать, возьми да и сам попробуй. Делов-то.
V>Зачем мне пробовать кактус?
Чтобы хоть немного просветиться и не говорить чушь

V>>>Это ничуть не пример, это тоже самое что я отдельно скопирую репу свн в отдельный каталог и буду работать с ней независимо как и с исходной. Где пример с большим количеством народу и одной историей на всех?
V>·>Просто _разберись_ что такое такое fork в github. Подсказка: pull requests.
V>И где там общая история?
В грАфе истории

V>·>А что по-твоему такое статистика?!
V>Ты читай внимательно что там измеряли, а измеряли там количество запросов по ключевым словам, т.е. в попугаях в вакууме, что ни разу не говорит о количестве серверов и статистике использования. Если народ не понимает как git использовать, он будет генерить массу запросов в гугл, что ни разу ни показатель хорошесть git, а скорее наоборот.
V>А статистикой будет, к примеру, количество скачиваний+установок[+удалений] или количество активных репозиториев на разных опенспейс доменах.
V>Вот, к примеру, статистика по Preforce Helix (крутить вниз к цифрам): https://www.perforce.com/helix
V>

V>Users: 36k
V>Transactions/day: 47M
V>Megabytes: 36M

"Complete ecosystem for Git-based development"... ах, вот оно как.

V>>>Так где мувинг то? Как работал репозиторий, так и работает.
V>·>Так английский ты тоже не знаешь? Ну там "present continuous"... ничего не говорит?
V>·>Короче, приведи перевод той цитаты, даже любопытно.
V>Причем здесь перевод? Когда есть факт текущего использования? Не говори гоп пока не перепрыгнешь.
Да, как legacy. А что делать-то? Вот постепенно и переезжают.

Здравствуйте, Vain, Вы писали:

V>А с чего ты тогда взял что Perforce виноват а не какой-нить раутер между точками? Перфорс используют туча народу и такая проблема бы сразу была заметна всем.

Потому что если бы проблема была в раутерах, то ее бы решили. Не

Туча народа использует P4 локально, где P4 и network latency не играют такой роли.

Иначе, при удаленных транзауциях делают pipelining. Вместо каждого мелкого запрос-ответ делается параллелизация запроса.


Но для меня все это имет крайне маловажное значение т.к.

1. Разобраться с git не составило проблем
2. Все мое уже давно перенесено в git вместе с историей
3. Проблемы EA и P4 остались далеко позади.
4. ... Если бы я был IT в EA: Проблемы и обсуждения такого рода должны решаться быстро и эффективно. Эффективный и быстрый поиск (полминуты для меня):



Первая ссылка,

Jul 15, 2014

. Что согласуется с наблюдениями 2011 г. И задает направление поиска.

Для тех кому еще это важно.

Здравствуйте, ·, Вы писали:

V>>Ещё раз, общее место для коммита/апдейта необходимо всегда, где там децентрализация, если УЖЕ требуется общая часть-центр для обмена? Пчёлы против мёда?
·>Это общее место — локальный репо.
Твой дом это общее место?

V>>По новому кругу идём. Как ты случайному челу передашь свои изменения, будешь его сам искать и предлагать свои изменения, или передашь в общий/центральный репозиторий, где он сам возьмёт?
·>Да. Или он сам возьмёт у тебя, если ты расшаришь доступ к своему репо.
Я не собираюсь никому ничего расшаривать, это бред, есть общее место — туда и заливай.

V>>Зачем мне пробовать кактус?
·>Чтобы хоть немного просветиться и не говорить чушь
Чушь это расшаривать что-то кому-то.

V>>И где там общая история?
·>В грАфе истории
А зачем ты врёшь? Там 2 разные истории.

·>"Complete ecosystem for Git-based development"... ах, вот оно как.
Ну да, на базе их движка

V>>Причем здесь перевод? Когда есть факт текущего использования? Не говори гоп пока не перепрыгнешь.
·>Да, как legacy. А что делать-то? Вот постепенно и переезжают.
А вот и ныне там (С)

Здравствуйте, Vetal_ca, Вы писали:

V>>А с чего ты тогда взял что Perforce виноват а не какой-нить раутер между точками? Перфорс используют туча народу и такая проблема бы сразу была заметна всем.
V_>Потому что если бы проблема была в раутерах, то ее бы решили. Не
V_>Туча народа использует P4 локально, где P4 и network latency не играют такой роли.
В EA которая разбросана по шарику как раз удалённо качают гигабайты.

V_>
V_>Первая ссылка,

Jul 15, 2014

. Что согласуется с наблюдениями 2011 г. И задает направление поиска.

ALAMEDA, Calif. (July 15, 2014) Perforce Software today announced a new federated architecture for the company’s version management engine, P4D, significantly reducing workflow latency across the development pipeline. Remote services, or Edge services, allow organizations to deploy full-scale versioning services closer to distributed teams to provide LAN-speed access to their source code, art files, documents and other assets they version in Perforce.

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

Здравствуйте, Vain, Вы писали:

V>>>Ещё раз, общее место для коммита/апдейта необходимо всегда, где там децентрализация, если УЖЕ требуется общая часть-центр для обмена? Пчёлы против мёда?
V>·>Это общее место — локальный репо.
V>Твой дом это общее место?
Нет.

V>>>По новому кругу идём. Как ты случайному челу передашь свои изменения, будешь его сам искать и предлагать свои изменения, или передашь в общий/центральный репозиторий, где он сам возьмёт?
V>·>Да. Или он сам возьмёт у тебя, если ты расшаришь доступ к своему репо.
V>Я не собираюсь никому ничего расшаривать, это бред, есть общее место — туда и заливай.
Как минимум таких общих мест может быть несколько.

V>>>Зачем мне пробовать кактус?
V>·>Чтобы хоть немного просветиться и не говорить чушь
V>Чушь это расшаривать что-то кому-то.
Залить в общее место это тоже расшарить.

V>>>И где там общая история?
V>·>В грАфе истории
V>А зачем ты врёшь? Там 2 разные истории.
Я не вру, просто ты не хочешь разобраться. История одна, если юзеры делают коммиты — то история разветвляется (т.е. возникают ветки). При мержах — опять сливается. Если все всё смержат — у всех будет идентичная общая история всех коммитов от всех юзеров.

V>А статистикой будет, к примеру, количество скачиваний+установок[+удалений] или количество активных репозиториев на разных опенспейс доменах.
Кстати, поинтересуйся размером одного только домена github.com, тут немного есть. На сегодняшний день он крупнейший в мире хостер исходников. А если сюда прибавить github enterprise и кучу других репо-менеджеров...

V>·>"Complete ecosystem for Git-based development"... ах, вот оно как.
V>Ну да, на базе их движка
Движка чего?

V>>>Причем здесь перевод? Когда есть факт текущего использования? Не говори гоп пока не перепрыгнешь.
V>·>Да, как legacy. А что делать-то? Вот постепенно и переезжают.
V>А вот и ныне там (С)
Проект масштаба boost в состоянии "in moving" запросто может быть несколько лет.

Здравствуйте, ·, Вы писали:

V>>Я не собираюсь никому ничего расшаривать, это бред, есть общее место — туда и заливай.
·>Как минимум таких общих мест может быть несколько.
Мне плевать сколько их, я хочу брать из одного и класть в одно. И таких как я — тьма.

V>>Чушь это расшаривать что-то кому-то.
·>Залить в общее место это тоже расшарить.
Кто про твоё общее место знает? Если вас в команде больше 10ка, остальным будет тупо плевать на твои локально-игрушечные репозитории. Поэтому вся идеалогия распределённости просто разваливается как карточный домик.

V>>>>И где там общая история?
V>>·>В грАфе истории
V>>А зачем ты врёшь? Там 2 разные истории.
·>Я не вру, просто ты не хочешь разобраться. История одна, если юзеры делают коммиты — то история разветвляется (т.е. возникают ветки).
Где ветки если корня нет? О чём ты говоришь?

·>При мержах — опять сливается. Если все всё смержат — у всех будет идентичная общая история всех коммитов от всех юзеров.
Это будут две разные истории, пусть даже в одной будет частично копия другой. Одна история должна всегда идти линейно.

V>>А статистикой будет, к примеру, количество скачиваний+установок[+удалений] или количество активных репозиториев на разных опенспейс доменах.
·>Кстати, поинтересуйся размером одного только домена github.com, тут немного есть. На сегодняшний день он крупнейший в мире хостер исходников. А если сюда прибавить github enterprise и кучу других репо-менеджеров...
Ну так ты сравни с другими хостерами, которые не только гит предлагают.
Кстати, на гитхабе куча всякого шлака хостится потому-что бесплатно, типа этого: https://github.com/WhiteHouse
Отсюда и завышенная статистика.

V>>·>"Complete ecosystem for Git-based development"... ах, вот оно как.
V>>Ну да, на базе их движка
·>Движка чего?
vcs, perforce использует свою базу и показывает коммиты git'а как свои changelist'ы

V>>·>Да, как legacy. А что делать-то? Вот постепенно и переезжают.
V>>А вот и ныне там (С)
·>Проект масштаба boost в состоянии "in moving" запросто может быть несколько лет.
А в чем проблема? Там около 150 библиотек, все сгруппировано по папкам, бери да перености. К тому же есть готовые инструменты для переноса: https://help.github.com/articles/source-code-migration-tools/
Ты думаешь они за год не могли перенести весь буст? Не верю (C).

Здравствуйте, Vain, Вы писали:

V>>>Я не собираюсь никому ничего расшаривать, это бред, есть общее место — туда и заливай.
V>·>Как минимум таких общих мест может быть несколько.
V>Мне плевать сколько их, я хочу брать из одного и класть в одно. И таких как я — тьма.
Да пожалуйста. Хочешь — клади в одно. Но если понадобится что-то иное — сделать бэкап, обменяться незаконченной работой с коллегой, переслать изменения на другой свой компьютер или виртуалку — и внезапно мест становится много.

V>>>Чушь это расшаривать что-то кому-то.
V>·>Залить в общее место это тоже расшарить.
V>Кто про твоё общее место знает? Если вас в команде больше 10ка, остальным будет тупо плевать на твои локально-игрушечные репозитории.
Ну наконец-то дошло! Вот видишь — можно как оказалось заводить свои приватные локально-игрушечные репозитории для своих личных целей без всяких админов/ревьюверов.

V>Поэтому вся идеалогия распределённости просто разваливается как карточный домик.
И поэтому даже этот твой самый perforce внезапно стал распределённые фичи вводить.

V>>>·>В грАфе истории
V>>>А зачем ты врёшь? Там 2 разные истории.
V>·>Я не вру, просто ты не хочешь разобраться. История одна, если юзеры делают коммиты — то история разветвляется (т.е. возникают ветки).
V>Где ветки если корня нет? О чём ты говоришь?
Корень есть, конечно, форк/клон же делается от какого-то существующего репо, как правило.

V>·>При мержах — опять сливается. Если все всё смержат — у всех будет идентичная общая история всех коммитов от всех юзеров.
V>Это будут две разные истории, пусть даже в одной будет частично копия другой. Одна история должна всегда идти линейно.
Нет конечно, копий нет. История нелинейная. См. DAG. Просто git умеет мержить, в отличие от примитивных систем контроля версий типа svn.

V>>>А статистикой будет, к примеру, количество скачиваний+установок[+удалений] или количество активных репозиториев на разных опенспейс доменах.
V>·>Кстати, поинтересуйся размером одного только домена github.com, тут немного есть. На сегодняшний день он крупнейший в мире хостер исходников. А если сюда прибавить github enterprise и кучу других репо-менеджеров...
V>Ну так ты сравни с другими хостерами, которые не только гит предлагают.
С какими? Я же говорю, github — крупнейший в мире.

V>Кстати, на гитхабе куча всякого шлака хостится потому-что бесплатно, типа этого: https://github.com/WhiteHouse
V>Отсюда и завышенная статистика.
Допустим и шлак и что?.. Типа шлак хостить легче?

V>>>·>"Complete ecosystem for Git-based development"... ах, вот оно как.
V>>>Ну да, на базе их движка
V>·>Движка чего?
V>vcs, perforce использует свою базу и показывает коммиты git'а как свои changelist'ы
helix это вообще-то интегрированная инфраструктура нескольких компонент типа TFS, а vcs компонента так же выбирается — либо p4, либо git.

V>>>А вот и ныне там (С)
V>·>Проект масштаба boost в состоянии "in moving" запросто может быть несколько лет.
V>А в чем проблема? Там около 150 библиотек, все сгруппировано по папкам, бери да перености. К тому же есть готовые инструменты для переноса: https://help.github.com/articles/source-code-migration-tools/
V>Ты думаешь они за год не могли перенести весь буст? Не верю (C).
Как я понял, они не просто переносят, но и разделяют один огромный мега-проект на множество независимых библиотек. А вообще говоря, как я вижу разработка ведётся в основном в git, если ты посмотришь странички how to contribute, то там описывается именно git:

Attach a diff to Boost developers list message explaining the patch. Easy to do, but least effective.
Attach a diff to a patch ticket. Less likely to get lost in the shuffle than a mailing list attachment, but many developers prefer to get pull requests (see below).

Здравствуйте, ·, Вы писали:

V>>Мне плевать сколько их, я хочу брать из одного и класть в одно. И таких как я — тьма.
·>Да пожалуйста. Хочешь — клади в одно. Но если понадобится что-то иное — сделать бэкап, обменяться незаконченной работой с коллегой, переслать изменения на другой свой компьютер или виртуалку — и внезапно мест становится много.


V>>·>Залить в общее место это тоже расшарить.
V>>Кто про твоё общее место знает? Если вас в команде больше 10ка, остальным будет тупо плевать на твои локально-игрушечные репозитории.
·>Ну наконец-то дошло! Вот видишь — можно как оказалось заводить свои приватные локально-игрушечные репозитории для своих личных целей без всяких админов/ревьюверов.
Ты и так это можешь делать, без всяких гитов. Все системы контроля это позволяют.

V>>Поэтому вся идеалогия распределённости просто разваливается как карточный домик.
·>И поэтому даже этот твой самый perforce внезапно стал распределённые фичи вводить.
Какие к примеру?

V>>·>Я не вру, просто ты не хочешь разобраться. История одна, если юзеры делают коммиты — то история разветвляется (т.е. возникают ветки).
V>>Где ветки если корня нет? О чём ты говоришь?
·>Корень есть, конечно, форк/клон же делается от какого-то существующего репо, как правило.
Его нету, потому-что две разные базы, каждая со своей историей.

V>>·>При мержах — опять сливается. Если все всё смержат — у всех будет идентичная общая история всех коммитов от всех юзеров.
V>>Это будут две разные истории, пусть даже в одной будет частично копия другой. Одна история должна всегда идти линейно.
·>Нет конечно, копий нет. История нелинейная. См. DAG. Просто git умеет мержить, в отличие от примитивных систем контроля версий типа svn.
Щито? Свн тоже умеет мержить, с добрым утром. Это на сегодняшний день вообще все системы контроля версий умеют.

V>>Отсюда и завышенная статистика.
·>Допустим и шлак и что?.. Типа шлак хостить легче?
типа бесплатно можно и шлак.

V>>·>Движка чего?
V>>vcs, perforce использует свою базу и показывает коммиты git'а как свои changelist'ы
·>helix это вообще-то интегрированная инфраструктура нескольких компонент типа TFS, а vcs компонента так же выбирается — либо p4, либо git.
Это не компонента, это переходник туда обратно, чтобы перетаскивать юзеров

Здравствуйте, Vain, Вы писали:


V>ALAMEDA, Calif. (July 15, 2014) Perforce Software today announced a new federated architecture for the company’s version management engine, P4D, significantly reducing workflow latency across the development pipeline. Remote services, or Edge services, allow organizations to deploy full-scale versioning services closer to distributed teams to provide LAN-speed access to their source code, art files, documents and other assets they version in Perforce.
V>[/q]
V>Так они что-то вроде прокси-кластера сделали, чтобы уменьшить общую нагрузку на центральный репозиторий. Я думаю в этом случае ни гит, ни свн уж подавно не способны справиться с такой нагрузкой, если уж кластер понадобился.

Нет, не по этому

git работает с сервером в момент clone, push и pull. И то только если нужно работать именно с этим remote, что для полноценной работы вовсе не обязательно.

Perforce работает с сервером покаждому чиху. Постоянно.
Чтобы обойти эту концептуальную проблему Perforce и понадобился кластер. То что я имел честь наблюдать на практике.

Здравствуйте, Vetal_ca, Вы писали:

V_>Perforce работает с сервером покаждому чиху. Постоянно.
А почему Perforce не должен работать постоянно, это же не только vcs, а система постоянного мониторинга файлов, changelist'ов, веток и других пользователей? Я, к примеру, могу видеть что другие пользователи делают просто нажав F5 на депозитории или группе файлов.

V_>Чтобы обойти эту концептуальную проблему Perforce и понадобился кластер. То что я имел честь наблюдать на практике.
На практике ты имел честь наблюдать скорее перегруз от миллиона запросов в секунду.

HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?

Неделя, это, конечно, перебор
У меня такое было в меньших масштабах — уже в конце рабочего дня, перед коммитом, что-то как-то не туда даванул в коммандере и похерил последние 4 часа своего труда. Сначала чуть в обморок не шарахнулся, потом оклемался и начал заново писать. Звонит шеф часа через два: "ты на работе до сих пор? да забей, потом доделаешь!". Вот так. Внимательней надо быть
А этот тип сам виноват отчасти — если контора не может организовать нормальный бэкап, организуй его себе сам. Или не работай там. И нечего тут потеряшку беспомощного строить

Здравствуйте, Vain, Вы писали:

V>>>Мне плевать сколько их, я хочу брать из одного и класть в одно. И таких как я — тьма.
V>·>Да пожалуйста. Хочешь — клади в одно. Но если понадобится что-то иное — сделать бэкап, обменяться незаконченной работой с коллегой, переслать изменения на другой свой компьютер или виртуалку — и внезапно мест становится много.
V>
Ага, точно — тьма и мрак.

V>>>Кто про твоё общее место знает? Если вас в команде больше 10ка, остальным будет тупо плевать на твои локально-игрушечные репозитории.
V>·>Ну наконец-то дошло! Вот видишь — можно как оказалось заводить свои приватные локально-игрушечные репозитории для своих личных целей без всяких админов/ревьюверов.
V>Ты и так это можешь делать, без всяких гитов. Все системы контроля это позволяют.
Нет, не все.

V>>>Поэтому вся идеалогия распределённости просто разваливается как карточный домик.
V>·>И поэтому даже этот твой самый perforce внезапно стал распределённые фичи вводить.
V>Какие к примеру?
https://www.perforce.com/support/tutorial-video-library/video/distributed-versioning-tutorial

V>>>Где ветки если корня нет? О чём ты говоришь?
V>·>Корень есть, конечно, форк/клон же делается от какого-то существующего репо, как правило.
V>Его нету, потому-что две разные базы, каждая со своей историей.
Ты это так уверенно заявляешь. И ты хоть как-то это можешь подвердить?

V>>>·>При мержах — опять сливается. Если все всё смержат — у всех будет идентичная общая история всех коммитов от всех юзеров.
V>>>Это будут две разные истории, пусть даже в одной будет частично копия другой. Одна история должна всегда идти линейно.
V>·>Нет конечно, копий нет. История нелинейная. См. DAG. Просто git умеет мержить, в отличие от примитивных систем контроля версий типа svn.
V>Щито? Свн тоже умеет мержить, с добрым утром. Это на сегодняшний день вообще все системы контроля версий умеют.
Нет, если ты имеешь в виду "svn merge", то видимо ты доку не читал: "Apply the differences between two sources to a working copy path." Т.е. это банально наложение патча на wc.
Сравни с "git merge" докой: "Join two or more development histories together". Т.е. мерж как слияние истории. А то что делает svn это больше соответствует одному из сценариев "rebase": "Reapply commits on top of another base tip", т.е. наложение коммитов (патчей) поверх другой истории.
В svn вроде есть какой-то костыль в виде merge tracking info, но это мрак и тьма.

V>>>Отсюда и завышенная статистика.
V>·>Допустим и шлак и что?.. Типа шлак хостить легче?
V>типа бесплатно можно и шлак.
Этот шлак не особо и развивается, и нагрузку не создаёт. Но в github есть очень много популярных и активных проектов.
А вообще, посмотришь на любой internal repo какой-нибудь старой большой богатой организации — там шлака столько же.
И что ты хочешь доказать-то?

V>>>·>Движка чего?
V>>>vcs, perforce использует свою базу и показывает коммиты git'а как свои changelist'ы
V>·>helix это вообще-то интегрированная инфраструктура нескольких компонент типа TFS, а vcs компонента так же выбирается — либо p4, либо git.
V>Это не компонента, это переходник туда обратно, чтобы перетаскивать юзеров
Переходник откуда и куда? Я ничего не понял.