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

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

Это и оборачивается в факап P4 при распределенной командной разработке что и требует вспомогательных костылей

V>На практике ты имел честь наблюдать скорее перегруз от миллиона запросов в секунду.

Ты не просто не понимаешь а еще пытаешся угадать

"Простой перегруз" это простое объяснение для людей не понимающих в распределенной обработке и архитектуре. Еще можно молотком постучать. Может, поможет. Ага.

Простой перегруз прекрасно лечится более быстрым серевером и/или широким каналом.

Но если в локальной сети все работает быстро а удаленно — нет, при достаточном канале, то здесь решить можно только переделкой продукта или его заменой. Ибо ограничено при неизменности продукта network latency, где значительный компонент это скорость света (сигнала по проводам).

Возвращаясь к исходному факапу P4, здесь все очевидно (для меня), понятно и дальнейшее обсуждение исчерпано ибо бессмысленно за неимением базы.

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

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

V>>Ты и так это можешь делать, без всяких гитов. Все системы контроля это позволяют.
·>Нет, не все.
свн и перфорс позволяют создать сервер локально.

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

You can push and fetch content on all these servers with the protections you are accustomed to in the Helix master server.

По твоей идеалогии это нифига не распределённо, раз есть центральный сервер.

V>>Его нету, потому-что две разные базы, каждая со своей историей.
·>Ты это так уверенно заявляешь. И ты хоть как-то это можешь подвердить?
На разнах компах находятся, в каждом своя история. Чем не подтверждение?

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", т.е. наложение коммитов (патчей) поверх другой истории.
В свн ты мержишь локально между коммитами, которые и формируют историю, т.е. в свн честная история.

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

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

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

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

V>>На практике ты имел честь наблюдать скорее перегруз от миллиона запросов в секунду.
V_>Я прекарсно понимаю что происходит, тут очевидно ты за мной медленно догоняешь происходящее. Не нужно перекручивать.
V_>Возвращаясь к исходному факапу P4, здесь все очевидно, понятно и дальнейшее обсуждение исчерпано.
Больше похоже, что ты себе какое-то оправдание придумал и уверовал в него. А все остальные пользователи используют Perforce и не плюются.

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

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


V>Больше похоже, что ты себе какое-то оправдание придумал и уверовал в него. А все остальные пользователи используют Perforce и не плюются.

Это ты не понимаешь что такое network latency и делаешь выводы не догадываясь о сути проблемы.

Если пошли выводы "все остальные, общепринято, всегда" — уровень компетенции собеседника исчерпан.

Я привел пример проблемы с распределенной командой и удаленными офисами. Чтобы не было бесполезного монолога почитай, что такое Protocol pipelining

Пока же это бесполезная потеря времени

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

V>>>·>Да пожалуйста. Хочешь — клади в одно. Но если понадобится что-то иное — сделать бэкап, обменяться незаконченной работой с коллегой, переслать изменения на другой свой компьютер или виртуалку — и внезапно мест становится много.
V>>>
V>·>Ага, точно — тьма и мрак.
V>Ага, пытаюсь тебе объяснить, что первым делом нужна фича положить/взять на/с сервер(а) а не положить соседу в репу. А ты "хочешь — клади в одно".
Да пожалуйста, гит не запрещает тебе иметь центральный сервер. Плохо, когда эта фича и первым делом и последним является, хочешь положить соседу в репу, а не можешь.

V>>>Ты и так это можешь делать, без всяких гитов. Все системы контроля это позволяют.
V>·>Нет, не все.
V>свн и перфорс позволяют создать сервер локально.
Как клон какого-то существующего репо? Да чтобы потом замержить новые изменения обратно?

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

V>You can push and fetch content on all these servers with the protections you are accustomed to in the Helix master server.

V>По твоей идеалогии это нифига не распределённо, раз есть центральный сервер.
У тебя с логикой беда. Распределённо это когда есть возможность распределить, т.е. опциональность центрального сервера, а не запрет на наличие центрального сервера.

V>>>Его нету, потому-что две разные базы, каждая со своей историей.
V>·>Ты это так уверенно заявляешь. И ты хоть как-то это можешь подвердить?
V>На разнах компах находятся, в каждом своя история. Чем не подтверждение?
Ага, только эта история — идентична. "своя история" существует только до мержа.

V>>>Щито? Свн тоже умеет мержить, с добрым утром. Это на сегодняшний день вообще все системы контроля версий умеют.
V>·>Нет, если ты имеешь в виду "svn merge", то видимо ты доку не читал: "Apply the differences between two sources to a working copy path." Т.е. это банально наложение патча на wc.
V>В свн есть свой панельный мержер, где можно руками мержить в случае коллизии.
А в Киеве — дядька. Причём тут коллизии?

V>·>Сравни с "git merge" докой: "Join two or more development histories together". Т.е. мерж как слияние истории. А то что делает svn это больше соответствует одному из сценариев "rebase": "Reapply commits on top of another base tip", т.е. наложение коммитов (патчей) поверх другой истории.
V>В свн ты мержишь локально между коммитами, которые и формируют историю, т.е. в свн честная история.
Ты не мержишь, а просто делаешь дифф между двумя коммитами и накладываешь его на текующую wc и делаешь новый коммит, который никак логически не связан в _истории_ с первыми двумя. Кроме как корявый mergeinfo.

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

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

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

V>>Ага, пытаюсь тебе объяснить, что первым делом нужна фича положить/взять на/с сервер(а) а не положить соседу в репу. А ты "хочешь — клади в одно".
·>Да пожалуйста, гит не запрещает тебе иметь центральный сервер. Плохо, когда эта фича и первым делом и последним является, хочешь положить соседу в репу, а не можешь.
С чего вдруг я должен хотеть, если я даже не знаю где этот сосед? В общем случае таких соседов дофигища и мне болт положить, что они там у себя в репозиториях нахреначили.

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

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

V>>В свн ты мержишь локально между коммитами, которые и формируют историю, т.е. в свн честная история.
·>Ты не мержишь, а просто делаешь дифф между двумя коммитами и накладываешь его на текующую wc и делаешь новый коммит, который никак логически не связан в _истории_ с первыми двумя. Кроме как корявый mergeinfo.
У тебя есть исходный файл и, к примеру, файл из бранча, который ты как раз мержишь. Они физически по разным путям, не понимаю причём здесь дифф, если он существует только для одного и того же файла.

V>>То, что больше пользуются бесплатно самим хостингом для хранения файла, а не самим гитом. Тут играет роль удобство сервиса, а не фичи гита, которые ты пытаешься продемонстрировать в доказательство популярности GitHub'а.
·>Ну а перфорс везде и всегда используется для хранения исключительно нетленных гениальных исходников. Забабахать туда пачку файлов ради "шоб было" типа нельзя...
Причем здесь перфорс, если речь про бесплатный хостер на базе версионирования?

V>>·>Переходник откуда и куда? Я ничего не понял.
V>>Перетаскивать юзеров с гита на перфорс, это же очевидно.
·>helix чтобы перетаскивать с git на p4? И много ты таких перетасканных наблюдал?
Это надо спросить у перфорса, сколько клиентов перешли на их сервис.

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

V>>>Ага, пытаюсь тебе объяснить, что первым делом нужна фича положить/взять на/с сервер(а) а не положить соседу в репу. А ты "хочешь — клади в одно".
V>·>Да пожалуйста, гит не запрещает тебе иметь центральный сервер. Плохо, когда эта фича и первым делом и последним является, хочешь положить соседу в репу, а не можешь.
V>С чего вдруг я должен хотеть, если я даже не знаю где этот сосед? В общем случае таких соседов дофигища и мне болт положить, что они там у себя в репозиториях нахреначили.
Ты не хочешь (как мне кажется лишь потому, что не умеешь), другие хотят.

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

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

V>Будут копии кусков одного в другом, это не полная история.
Копии будут в vcs которые мержить не умеют, типа svn.
Прежде чем заявлять очередную глупость, скажи, ты разобрался с history DAG?

V>>>В свн ты мержишь локально между коммитами, которые и формируют историю, т.е. в свн честная история.
V>·>Ты не мержишь, а просто делаешь дифф между двумя коммитами и накладываешь его на текующую wc и делаешь новый коммит, который никак логически не связан в _истории_ с первыми двумя. Кроме как корявый mergeinfo.
V>У тебя есть исходный файл и, к примеру, файл из бранча, который ты как раз мержишь. Они физически по разным путям,
Что такое "исходный файл"? И какая его взаимосвязь с "файлом из бранча"?

V>не понимаю причём здесь дифф,
выделил специально для тебя:

svn merge — Apply the differences between two sources to a working copy path.

(с) http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.merge.html

V>если он существует только для одного и того же файла.
Мерж в svn это получение разницы между изменениями сделанными в одном бранче и применение этой разницы к рабочей копии. Так?

V>>>То, что больше пользуются бесплатно самим хостингом для хранения файла, а не самим гитом. Тут играет роль удобство сервиса, а не фичи гита, которые ты пытаешься продемонстрировать в доказательство популярности GitHub'а.
V>·>Ну а перфорс везде и всегда используется для хранения исключительно нетленных гениальных исходников. Забабахать туда пачку файлов ради "шоб было" типа нельзя...
V>Причем здесь перфорс, если речь про бесплатный хостер на базе версионирования?
Платность-бесплатность тут не причём. github тоже не всегда бесплатный. Мало того, был вот бесплатный sourceforge на базе svn — почему он не крупнейший?

V>>>Перетаскивать юзеров с гита на перфорс, это же очевидно.
V>·>helix чтобы перетаскивать с git на p4? И много ты таких перетасканных наблюдал?
V>Это надо спросить у перфорса, сколько клиентов перешли на их сервис.
Спроси, посмеёмся.

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

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

V>>Мерж двух каталогов, эта тулзовина даже отношения к vcs не имеет.
·>А что имеет?
·>Собственно если эти два каталога — две немного разные версии исходников одного и того же проекта, то это прямая обязанность любой приличной vcs дать возможность их всяко сравнивать и мержить.
Не обязательно. В этом суть простоты vcs, которая позволяет использовать всем привычные вещи как, к примеру, голую файловую систему и любую тулзовину для мержа на ней.

V>>Ты же не всю историю мержишь, а только часть, какую-то ветку, следовательно, там никогда полной истории и не будет.
·>Не понимаю к чему ты это говоришь. Ну если тебе нужно замержить часть, то будет частично смерженная история. Если тебе нужно замержить всё, история будет полностью смерженной. Почему никогда?
Я хочу всегда полную и действительную историю всего репозитория, а не куски разбросанные по локальным компам. И мне плевать сколько юзер сделал у себя коммитов в игрушечном репозитории. Это больше напрягает, чем решает какие-то проблемы.

V>>Будут копии кусков одного в другом, это не полная история.
·>Копии будут в vcs которые мержить не умеют, типа svn.
Я пока одни глупости про свн от тебя слышу.

·>Прежде чем заявлять очередную глупость, скажи, ты разобрался с history DAG?
разберись сначала с простой системой типа свн.

V>>У тебя есть исходный файл и, к примеру, файл из бранча, который ты как раз мержишь. Они физически по разным путям,
·>Что такое "исходный файл"? И какая его взаимосвязь с "файлом из бранча"?
Такая что тебе общий файл нужен на выходе, а не их разница.

V>>не понимаю причём здесь дифф,
·>выделил специально для тебя:
·>

svn merge — Apply the differences between two sources to a working copy path.

(с) http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.merge.html
Ну да, это он делает для хранения истории изменений. А алгоритмов слить 1/2/100500 файлов в один я думаю найдётся масса.

V>>если он существует только для одного и того же файла.
·>Мерж в svn это получение разницы между изменениями сделанными в одном бранче и применение этой разницы к рабочей копии. Так?
Мерж это слияние контента файлов и дерева файлов/каталогов, плюс для свн, свойств файлов. А также автоматическое разрешение коллизий с ручным управлением в случае коллизий.

V>>Причем здесь перфорс, если речь про бесплатный хостер на базе версионирования?
·>Платность-бесплатность тут не причём. github тоже не всегда бесплатный. Мало того, был вот бесплатный sourceforge на базе svn — почему он не крупнейший?
У сорсфоржа с управлением хуже. К тому же оно выглядит и ощущается перегруженным. У гитхаба это сделано много проще. К примеру, не все хотят делать отдельный архив с исходниками/бинарниками и заливать его отдельно. В гитхабе это просто кнопка download на репозитории с автоматическим архивированием содержимого.

V>>Это надо спросить у перфорса, сколько клиентов перешли на их сервис.
·>Спроси, посмеёмся.
Крупные компании просто ржут в голос.

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

V>>>С чего вдруг я должен хотеть, если я даже не знаю где этот сосед? В общем случае таких соседов дофигища и мне болт положить, что они там у себя в репозиториях нахреначили.
V>·>Ты не хочешь (как мне кажется лишь потому, что не умеешь), другие хотят.
V>Я вижу что другие тоже не хотят, потому-что это лишний геморрой с мержем чужого кода, никто этим не хочет заниматься.
Это тебе так кажется потому что ты не умеешь. А популярность pull requests тебе ни на что не намекает?

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

V>·>А что имеет?
V>·>Собственно если эти два каталога — две немного разные версии исходников одного и того же проекта, то это прямая обязанность любой приличной vcs дать возможность их всяко сравнивать и мержить.
V>Не обязательно. В этом суть простоты vcs, которая позволяет использовать всем привычные вещи как, к примеру, голую файловую систему и любую тулзовину для мержа на ней.
У тебя опять с логикой проблемы. "дать возможность" не означает, что возникает запрет на использование "привычних вещей". Как раз git позволяет на порядки проще взять голую файловую систему, превратить в репозиторий (git init), смержить с любым другим репозиторием (git fetch/merge), перекроить историю (graft/replace/filter-branch), потом обратно сделать голую файловую систему (rm -r .git) и т.д., и т.п. Svn-у такого и не снилось. Я даже натыкался на вопросы типа "как в svn сделать X" и ответы "импортните svn в git, сделайте X, экспортните git в svn".

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

V>Это больше напрягает, чем решает какие-то проблемы.
Ты, главное, не напрягайся.

V>>>Будут копии кусков одного в другом, это не полная история.
V>·>Копии будут в vcs которые мержить не умеют, типа svn.
V>Я пока одни глупости про свн от тебя слышу.
Ну да, глупости. А что поделаешь, я тебе тупо официальную доку svn цитирую и перевожу.

V>·>Прежде чем заявлять очередную глупость, скажи, ты разобрался с history DAG?
V>разберись сначала с простой системой типа свн.
Так ты разобрался с DAG? Как хоть это расшифровывается? И есть ли он в svn или там что-то другое?

V>>>У тебя есть исходный файл и, к примеру, файл из бранча, который ты как раз мержишь. Они физически по разным путям,
V>·>Что такое "исходный файл"? И какая его взаимосвязь с "файлом из бранча"?
V>Такая что тебе общий файл нужен на выходе, а не их разница.
А что по-твоему является результатом операции "apply the differences"?

V>>>не понимаю причём здесь дифф,
V>·>выделил специально для тебя:
V>·>

svn merge — Apply the differences between two sources to a working copy path.

(с) http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.merge.html
V>Ну да, это он делает для хранения истории изменений.
Что "это"?? Причём тут вообще хранение истории?

V>А алгоритмов слить 1/2/100500 файлов в один я думаю найдётся масса.
Перечисли плиз, _со ссылкой на доку svn_.

V>>>если он существует только для одного и того же файла.
V>·>Мерж в svn это получение разницы между изменениями сделанными в одном бранче и применение этой разницы к рабочей копии. Так?
В смысле ты считаешь это высказывание неверным?

V>Мерж это слияние контента файлов и дерева файлов/каталогов, плюс для свн, свойств файлов. А также автоматическое разрешение коллизий с ручным управлением в случае коллизий.
Это общие слова. А как конкретно это работает в svn?

V>>>Причем здесь перфорс, если речь про бесплатный хостер на базе версионирования?
V>·>Платность-бесплатность тут не причём. github тоже не всегда бесплатный. Мало того, был вот бесплатный sourceforge на базе svn — почему он не крупнейший?
V>У сорсфоржа с управлением хуже. К тому же оно выглядит и ощущается перегруженным.
Так почему хуже-то? Ну сделали бы sourceforge2.0 с лучшим управлением и чтобы выглядело разгруженным, в чём проблема-то?

V>У гитхаба это сделано много проще. К примеру, не все хотят делать отдельный архив с исходниками/бинарниками и заливать его отдельно. В гитхабе это просто кнопка download на репозитории с автоматическим архивированием содержимого.
Это конкретно не заслуга github, а фича git, читай доку по "git archive". Думай дальше.

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

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

·>А популярность pull requests тебе ни на что не намекает?
Что ещё за популярность? Звучит как популярность геев и садомазо.

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

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

V>>Я пока одни глупости про свн от тебя слышу.
·>Ну да, глупости. А что поделаешь, я тебе тупо официальную доку svn цитирую и перевожу.
Ты хотя бы вдумывайся для кого она написана и что там написано.

V>>разберись сначала с простой системой типа свн.
·>Так ты разобрался с DAG? Как хоть это расшифровывается? И есть ли он в svn или там что-то другое?
Да мне плевать, вот честно.

V>>Такая что тебе общий файл нужен на выходе, а не их разница.
·>А что по-твоему является результатом операции "apply the differences"?
Алгоритм не обязан apply differences делать, у него на входе целые файлы.

V>>Ну да, это он делает для хранения истории изменений.
·>Что "это"?? Причём тут вообще хранение истории?
Притом что это имеет смысл в случае хранения, в случае слияния это не обязательно так. Просто в случае поиска коллизий именно в текстовых файлах, удобнее их пользователю в читаемом виде показывать.

V>>А алгоритмов слить 1/2/100500 файлов в один я думаю найдётся масса.
·>Перечисли плиз, _со ссылкой на доку svn_.
С чего ты взял что в доке рассказано про внутренние алгоритмы свн?

V>>Мерж это слияние контента файлов и дерева файлов/каталогов, плюс для свн, свойств файлов. А также автоматическое разрешение коллизий с ручным управлением в случае коллизий.
·>Это общие слова. А как конкретно это работает в svn?
Щито? Это вообще суть мержа, т.е. его цель. То что дано получить имея что-то, а как это будет достигнуто — дело десятое.

V>>У сорсфоржа с управлением хуже. К тому же оно выглядит и ощущается перегруженным.
·>Так почему хуже-то? Ну сделали бы sourceforge2.0 с лучшим управлением и чтобы выглядело разгруженным, в чём проблема-то?
Так это не имеет отношения к vcs, что я тебе и пытаюсь здесь объяснить.

V>>У гитхаба это сделано много проще. К примеру, не все хотят делать отдельный архив с исходниками/бинарниками и заливать его отдельно. В гитхабе это просто кнопка download на репозитории с автоматическим архивированием содержимого.
·>Это конкретно не заслуга github, а фича git, читай доку по "git archive". Думай дальше.
Заслуга в том, что они сделали простое управление со списком коммитов и кнопкой. В сорсфорже по-другому, там надо изначально самому архив создать и залить.

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

V>·>Это тебе так кажется потому что ты не умеешь.
V>Ты путаешь не умею с не хочу.
Ну потому и "не хочешь", т.к. не умеешь.

V>·>А популярность pull requests тебе ни на что не намекает?
V>Что ещё за популярность? Звучит как популярность геев и садомазо.
Веский аргумент.

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


V>>>Я хочу всегда полную и действительную историю всего репозитория, а не куски разбросанные по локальным компам. И мне плевать сколько юзер сделал у себя коммитов в игрушечном репозитории.
V>·>Да пожалуйста, если хочешь. Если кто-то тебе запретил, скажи, что я разрешаю.
V>Ваша секта именно что навязывает эту идеалогию, нечего здесь кривляться якобы что ты здесь ни причём.
Бедненький... не больно? Но ты борись!

V>>>Я пока одни глупости про свн от тебя слышу.
V>·>Ну да, глупости. А что поделаешь, я тебе тупо официальную доку svn цитирую и перевожу.
V>Ты хотя бы вдумывайся для кого она написана и что там написано.
Вдумался. А по делу-то есть что сказать?

V>>>разберись сначала с простой системой типа свн.
V>·>Так ты разобрался с DAG? Как хоть это расшифровывается? И есть ли он в svn или там что-то другое?
V>Да мне плевать, вот честно.
Мракобесие это называется.

V>>>Такая что тебе общий файл нужен на выходе, а не их разница.
V>·>А что по-твоему является результатом операции "apply the differences"?
V>Алгоритм не обязан apply differences делать, у него на входе целые файлы.
Ок. Что делает команда svn merge по-твоему? И, пожалуйста, не будь голословен, подтверди свой ответ цитатами/ссылками.

V>>>Ну да, это он делает для хранения истории изменений.
V>·>Что "это"?? Причём тут вообще хранение истории?
V>Притом что это имеет смысл в случае хранения, в случае слияния это не обязательно так. Просто в случае поиска коллизий именно в текстовых файлах, удобнее их пользователю в читаемом виде показывать.
Ну так а как? Опиши алгоритм что делает svn merge.

V>>>А алгоритмов слить 1/2/100500 файлов в один я думаю найдётся масса.
V>·>Перечисли плиз, _со ссылкой на доку svn_.
V>С чего ты взял что в доке рассказано про внутренние алгоритмы свн?
Ок, ссылка на учебник или исходники svn тоже сгодится.

V>>>Мерж это слияние контента файлов и дерева файлов/каталогов, плюс для свн, свойств файлов. А также автоматическое разрешение коллизий с ручным управлением в случае коллизий.
V>·>Это общие слова. А как конкретно это работает в svn?
V>Щито? Это вообще суть мержа, т.е. его цель. То что дано получить имея что-то, а как это будет достигнуто — дело десятое.
Это понятно. Но дело нулевое — что именно умеет конкретная vcs. Так ты знаешь как это конкретно работает в svn?

V>>>У сорсфоржа с управлением хуже. К тому же оно выглядит и ощущается перегруженным.
V>·>Так почему хуже-то? Ну сделали бы sourceforge2.0 с лучшим управлением и чтобы выглядело разгруженным, в чём проблема-то?
V>Так это не имеет отношения к vcs, что я тебе и пытаюсь здесь объяснить.
Я знаю что пытаешься, но у тебя плохо получается. Так к чему имеет?

V>>>У гитхаба это сделано много проще. К примеру, не все хотят делать отдельный архив с исходниками/бинарниками и заливать его отдельно. В гитхабе это просто кнопка download на репозитории с автоматическим архивированием содержимого.
V>·>Это конкретно не заслуга github, а фича git, читай доку по "git archive". Думай дальше.
V>Заслуга в том, что они сделали простое управление со списком коммитов и кнопкой.
Что помешало в сорсфордже сделать такой же список и кнопку?

V>В сорсфорже по-другому, там надо изначально самому архив создать и залить.
Кстати, нет. Там есть кнопочка "Download snapshot".

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

V>>>Ну, к примеру, ms использует свой TFS или как там оно, который до этого был SourceSafe.
V>·>TFS вообще-то не vcs. TFS может использовать и git. Ты наверное с TFVC попутал. А так с недавнего времени (мы ж о трендах?) внезапно: "Git is the default version control provider for new projects".
V>Это маркетинг.

Here at Microsoft we have teams of all shapes and sizes, and many of them are already using Git or are moving that way.

Вот тебе, бабушка, и маркетинг!

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

V>>Это маркетинг.
·>

Here at Microsoft we have teams of all shapes and sizes, and many of them are already using Git or are moving that way.

·>Вот тебе, бабушка, и маркетинг!
Угу:

However, we also have a handful of teams with repos of unusual size! For example, the Windows codebase has over 3.5 million files and is over 270 GB in size. The Git client was never designed to work with repos with that many files or that much content. You can see that in action when you run “git checkout” and it takes up to 3 hours, or even a simple “git status” takes almost 10 minutes to run. That’s assuming you can get past the “git clone”, which takes 12+ hours.

Где тут гит вообще нормально справляется? Да с таким "справляется" сразу на помоечку. А ещё в соседней ветке на Pеrforce плевались.

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

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

·>Ну потому и "не хочешь", т.к. не умеешь.

V>>>>А алгоритмов слить 1/2/100500 файлов в один я думаю найдётся масса.
V>>·>Перечисли плиз, _со ссылкой на доку svn_.
V>>С чего ты взял что в доке рассказано про внутренние алгоритмы свн?
·>Ок, ссылка на учебник или исходники svn тоже сгодится.
Я же тебя не нанимался обучать, исходники в зубы и вперёд!

V>>Щито? Это вообще суть мержа, т.е. его цель. То что дано получить имея что-то, а как это будет достигнуто — дело десятое.
·>Это понятно. Но дело нулевое — что именно умеет конкретная vcs. Так ты знаешь как это конкретно работает в svn?
Как это разрешит твои проблемы неумения пользоваться простым инструментом?

V>>В сорсфорже по-другому, там надо изначально самому архив создать и залить.
·>Кстати, нет. Там есть кнопочка "Download snapshot".
Я про Summary и Files. Туда надо отдельно заливать.

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

V>>>·>Ты говоришь как будто это что-то плохое. Сделал ревью, выглядит хорошо — нажал кнопочку — оно и замержилось за долю секунды. Это ж не svn, где так называемый "merge" это целое приключение.
V>

V>·>Ну потому и "не хочешь", т.к. не умеешь.

?

V>>>>>А алгоритмов слить 1/2/100500 файлов в один я думаю найдётся масса.
V>>>·>Перечисли плиз, _со ссылкой на доку svn_.
V>>>С чего ты взял что в доке рассказано про внутренние алгоритмы свн?
V>·>Ок, ссылка на учебник или исходники svn тоже сгодится.
V>Я же тебя не нанимался обучать, исходники в зубы и вперёд!
Я их читал, в отличие от тебя. Фантазировать и балаболить я тебя тоже не нанимал.
Ну ладно, назови хоть штуки три из "массы".

V>>>Щито? Это вообще суть мержа, т.е. его цель. То что дано получить имея что-то, а как это будет достигнуто — дело десятое.
V>·>Это понятно. Но дело нулевое — что именно умеет конкретная vcs. Так ты знаешь как это конкретно работает в svn?
V>Как это разрешит твои проблемы неумения пользоваться простым инструментом?
Отлично разрешит, обо мне не беспокойся. Так как svn merge работает?

V>Я про Summary и Files. Туда надо отдельно заливать.
А, ясно. Но всё равно ты так и не объяснил почему такое же не сделали.

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

V>>Я же тебя не нанимался обучать, исходники в зубы и вперёд!
·>Я их читал, в отличие от тебя. Фантазировать и балаболить я тебя тоже не нанимал.
С чего я должен тебе здесь верить, если ты показал свою профнепригодность в пользовании свн? Это у тебя проблемы с мержем а не у меня.

V>>Как это разрешит твои проблемы неумения пользоваться простым инструментом?
·>Отлично разрешит, обо мне не беспокойся. Так как svn merge работает?
Там где надо, прекрасно работает. У тех кто не умеет — не работает.

V>>Я про Summary и Files. Туда надо отдельно заливать.
·>А, ясно. Но всё равно ты так и не объяснил почему такое же не сделали.
Потому-что они "особенные".

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

V>>>Я же тебя не нанимался обучать, исходники в зубы и вперёд!
V>·>Я их читал, в отличие от тебя. Фантазировать и балаболить я тебя тоже не нанимал.
V>С чего я должен тебе здесь верить, если ты показал свою профнепригодность в пользовании свн? Это у тебя проблемы с мержем а не у меня.
У меня проблем с мержем нет, не беспокойся ты так обо мне.
Я тебе задаю конкретный вопрос. Список алгоритмов мержа в студию, которые умеет svn merge. Я тебе даже помогу, раз у тебя вообще нулевые знания. Вот начни отсюда и попробуй подумать и выбрать те, которые умеет svn merge.

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

V>>·>Я их читал, в отличие от тебя. Фантазировать и балаболить я тебя тоже не нанимал.
V>>С чего я должен тебе здесь верить, если ты показал свою профнепригодность в пользовании свн? Это у тебя проблемы с мержем а не у меня.
·>У меня проблем с мержем нет, не беспокойся ты так обо мне.
Зачем тогда ты про мерж в свн плачишься? Если у тебя не было проблем, ты бы их не выставлял на всеобщее обозрение.

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

V>>>С чего я должен тебе здесь верить, если ты показал свою профнепригодность в пользовании свн? Это у тебя проблемы с мержем а не у меня.
V>·>У меня проблем с мержем нет, не беспокойся ты так обо мне.
V>Зачем тогда ты про мерж в свн плачишься? Если у тебя не было проблем, ты бы их не выставлял на всеобщее обозрение.
Я тебе задаю конкретный вопрос. Список алгоритмов мержа в студию, которые умеет svn merge. Я тебе даже помогу, раз у тебя вообще нулевые знания. Вот начни отсюда и попробуй подумать и выбрать те, которые умеет svn merge.

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

V>>·>У меня проблем с мержем нет, не беспокойся ты так обо мне.
V>>Зачем тогда ты про мерж в свн плачишься? Если у тебя не было проблем, ты бы их не выставлял на всеобщее обозрение.
·>Я тебе задаю конкретный вопрос. Список алгоритмов мержа в студию, которые умеет svn merge. Я тебе даже помогу, раз у тебя вообще нулевые знания. Вот начни отсюда и попробуй подумать и выбрать те, которые умеет svn merge.
Мои "нулевые" знания помогли мне разобраться с свн и использовать его на ура. Твои "ненулевые" тебе не помогли. Так что сам можешь начинать с азов.