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

V>>На той, что работу легко как раз похерить локально.
·>Так какой сервер-то? Counter Strike Server подойдёт?
Удалённый. Но ты продолжай ёрничать.

V>>Он может всё что угодно иметь, каким образом статистика собирается то?
·>Если факты тебе не нравятся — тем хуже для фактов...
Какие факты, пока что одни интерпретации.

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

V>>sourceforge опенсоурс.
·>Большое число проектов с sourceforge переехали в github.
Видел там и там.

V>>·>Это, конечно, мой частный случай, но я лично наблюдал в двух крупных банках переезд ClearCase -> git (и даже принимал в этом участие) и svn -> git.
V>>А я не наблюдал, дальше что?
·>А ты наблюдал переезды обратно?
Оупенсоурс в прайват? И как её можно наблюдать?

V>>·>Он там в почти в каждой строчке. Ещё лет 5 назад такого не было. И он, как правило, частично замещает существующие vcs.
V>>Что он там замещает то?
·>Существующие vcs.
Но они живее всех живых.

V>>Как, к примеру, гит заменит ревизии в свн?
·>git describe, build numbers, etc.
https://pukkaone.github.io/2010/12/19/build-number-git-repository.html
Куча каких то левых операций сделать чтобы только билд номер посмотреть? В свн это вообще из каропки и ничего не надо делать. Даже теги не надо ставить.

V>>Или простоту использования последнего?
·>Давно уж заменил.
Где?

V>>Это маркетинг.
·>Маркетинг чего? Линус проплатил Майкрософту?!
Майкрософт продаёт свои поделия комьюнити на хайпе.

V>>·>Геймдев обычно особенный, там очень много крупных бинарников, что не очень хорошо ложится в git из коробки. Но со всякими git annex, et al вангую лет 10-15 на заметное изменение ситуации в пользу git и в этой области.
V>>разве github не отказались от annex в пользу lfs?
·>Ах, ну раз lfs — это всё менят!
Т.е. твоё вангование про 10-15 лет это очередной заверон?

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

V>>>На той, что работу легко как раз похерить локально.
V>·>Так какой сервер-то? Counter Strike Server подойдёт?
V>Удалённый. Но ты продолжай ёрничать.
Блин, хватит изворачиваться! Так скажи уж толком-то! Какой сервер-то? Какой он сервис предоставляет?

V>>>Он может всё что угодно иметь, каким образом статистика собирается то?
V>·>Если факты тебе не нравятся — тем хуже для фактов...
V>Какие факты, пока что одни интерпретации.
Факт — интерес к гиту значительно превышает интерес к другим системам контроля версий. У тебя есть другие факты?

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

V>>>sourceforge опенсоурс.
V>·>Большое число проектов с sourceforge переехали в github.
V>Видел там и там.
Например?

V>>>·>Это, конечно, мой частный случай, но я лично наблюдал в двух крупных банках переезд ClearCase -> git (и даже принимал в этом участие) и svn -> git.
V>>>А я не наблюдал, дальше что?
V>·>А ты наблюдал переезды обратно?
V>Оупенсоурс в прайват? И как её можно наблюдать?
Переезд с гита на какую-то другую vcs.

V>>>Что он там замещает то?
V>·>Существующие vcs.
V>Но они живее всех живых.
Ага, просто они так пахнут.

V>>>Как, к примеру, гит заменит ревизии в свн?
V>·>git describe, build numbers, etc.
V>https://pukkaone.github.io/2010/12/19/build-number-git-repository.html
V>Куча каких то левых операций сделать чтобы только билд номер посмотреть? В свн это вообще из каропки и ничего не надо делать. Даже теги не надо ставить.
Это не единственный способ. Зависит от того что именно ты хочешь с этим номером делать и на кой он вообще нужен. Например, "git rev-list --count master" будет выдавать то, для чего обычно номер ревизии svn может быть использован в билдах.

V>>>Или простоту использования последнего?
V>·>Давно уж заменил.
V>Где?
Везде, самая явная простота — работа с бранчами.

V>>>Это маркетинг.
V>·>Маркетинг чего? Линус проплатил Майкрософту?!
V>Майкрософт продаёт свои поделия комьюнити на хайпе.
И ты правда ожидаешь, что хайп пройдёт и все опять с радостью полезут на sourcesafe?

V>>>·>Геймдев обычно особенный, там очень много крупных бинарников, что не очень хорошо ложится в git из коробки. Но со всякими git annex, et al вангую лет 10-15 на заметное изменение ситуации в пользу git и в этой области.
V>>>разве github не отказались от annex в пользу lfs?
V>·>Ах, ну раз lfs — это всё менят!
V>Т.е. твоё вангование про 10-15 лет это очередной заверон?
Ты читать не умеешь? Или не знаешь что такое "et al"?
Я вангую что перелезут на git со всяких префорсов. Но какую именно нашлёпку выберут для крупных бираников — annex, lfs, bigfiles, ... etc — я точно не знаю.

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

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

V>>Какие факты, пока что одни интерпретации.
·>Факт — интерес к гиту значительно превышает интерес к другим системам контроля версий. У тебя есть другие факты?
Только интерес? И это всё?

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

V>>·>Большое число проектов с sourceforge переехали в github.
V>>Видел там и там.
·>Например?
https://svn.boost.org/trac/boost/
https://github.com/boostorg
https://sourceforge.net/p/nsis/code/HEAD/tree/
https://github.com/kichik/nsis

V>>·>А ты наблюдал переезды обратно?
V>>Оупенсоурс в прайват? И как её можно наблюдать?
·>Переезд с гита на какую-то другую vcs.
Скорее попробуют гит, а потом вернуться.

V>>Но они живее всех живых.
·>Ага, просто они так пахнут.
А с чего ты взял что ощущаешь не свой запах?

V>>https://pukkaone.github.io/2010/12/19/build-number-git-repository.html
V>>Куча каких то левых операций сделать чтобы только билд номер посмотреть? В свн это вообще из каропки и ничего не надо делать. Даже теги не надо ставить.
·>Это не единственный способ. Зависит от того что именно ты хочешь с этим номером делать и на кой он вообще нужен. Например, "git rev-list --count master" будет выдавать то, для чего обычно номер ревизии svn может быть использован в билдах.
Лучше уж нафик нафик этот лесапет.

V>>Майкрософт продаёт свои поделия комьюнити на хайпе.
·>И ты правда ожидаешь, что хайп пройдёт и все опять с радостью полезут на sourcesafe?
Зачем, останутся каждый на своих vcs гораздо более привычных и простых.

·>Ты читать не умеешь? Или не знаешь что такое "et al"?
·>Я вангую что перелезут на git со всяких префорсов.
А что, у гита есть, к примеру, такая простая фича как шелвинг чтобы на него переходить? Даже свн её собирается ввести ибо поняли её полезность и эффективность.

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

V>·>Блин, хватит изворачиваться! Так скажи уж толком-то! Какой сервер-то? Какой он сервис предоставляет?
V>у любого античного vcs есть ремоут сервер, что ты придуриваешься?

Исправил. гиту оно необязательно.

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

Исправил снова. Не благодари.
Есть, но пользоваться им смысла нет никакого. Бранчи стоят дешево и работать с ними не в пример удобнее.

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

V>>у любого античного vcs есть ремоут сервер, что ты придуриваешься?
L>Исправил. гиту оно необязательно.
Доооо. В общий репозиторий теперь не нужно заливать.

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

L>Есть, но пользоваться им смысла нет никакого. Бранчи стоят дешево и работать с ними не в пример удобнее.
Щито? Я не хочу никаких бранчей, я хочу "положить в ящик" и пойти домой. Бранчи не могут быть дешевле этого.

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

V>·>Собственно, если у тебя есть возражения — подкрепи хоть какими-нибудь данными.
V>Ну, к примеру, ms использует свой TFS или как там оно, который до этого был SourceSafe. EA — perforce. Достаточно крупные компании для тебя?

Я лично имел дело с синхронизацией Perforce в EA между двумя удаленными командами. Одно неверное движение и репозиторий "замер" на 2 часа. Это уже сам по себе было настолько узкое место, что можно отнести к факап как есть.

Если еще не перешли на git, то так им и надо в рукотворном аду

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

V>·>Блин, хватит изворачиваться! Так скажи уж толком-то! Какой сервер-то? Какой он сервис предоставляет?
V>у любого vcs есть ремоут сервер, что ты придуриваешься?
У git нет сервера, если бы ты читал хотя бы то, что я тебе пишу, то давно бы понял что заблуждаешься. Можно иметь как сервер так называемый repository​ manager, который позволяет организовать множество репов для разных проектов, раздать права доступа, интегрировать с системой автобилдов, ревью, етс. Например, github.
Но в обсуждаемом тут сценарии "бэкап поломаных промежуточных изменений" сервер не нужен, можно самому создать ещё один репо и использовать его в личных целях.

V>>>Какие факты, пока что одни интерпретации.
V>·>Факт — интерес к гиту значительно превышает интерес к другим системам контроля версий. У тебя есть другие факты?
V>Только интерес? И это всё?
У тебя опять проблема с пониманием.

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

V>>>·>Большое число проектов с sourceforge переехали в github.
V>>>Видел там и там.
V>·>Например?
V>https://svn.boost.org/trac/boost/
V>https://github.com/boostorg
V>https://sourceforge.net/p/nsis/code/HEAD/tree/
V>https://github.com/kichik/nsis
А ты сам посмотрел эти ссылки?

Boost is moving from Subversion centralized version control to Git distributed modular version control.

Зачем ты мне доказываешь, что ты не прав? Я это и так знаю.

V>>>Оупенсоурс в прайват? И как её можно наблюдать?
V>·>Переезд с гита на какую-то другую vcs.
V>Скорее попробуют гит, а потом вернуться.
И ты это наблюдал? Или опять фантазии?
V>·>Это не единственный способ. Зависит от того что именно ты хочешь с этим номером делать и на кой он вообще нужен. Например, "git rev-list --count master" будет выдавать то, для чего обычно номер ревизии svn может быть использован в билдах.
V>Лучше уж нафик нафик этот лесапет.
Ну продолжай грызть свой кактус

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

V>·>Ты читать не умеешь? Или не знаешь что такое "et al"?
V>·>Я вангую что перелезут на git со всяких префорсов.
V>А что, у гита есть, к примеру, такая простая фича как шелвинг чтобы на него переходить? Даже свн её собирается ввести ибо поняли её полезность и эффективность.
Конечно, всегда была. "git stash" называется, и если тебе интересно внутреннее устройство, то реализована с помощью тех же бранчей.

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

V>>·>Собственно, если у тебя есть возражения — подкрепи хоть какими-нибудь данными.
V>>Ну, к примеру, ms использует свой TFS или как там оно, который до этого был SourceSafe. EA — perforce. Достаточно крупные компании для тебя?
V_>Я лично имел дело с синхронизацией Perforce в EA между двумя удаленными командами. Одно неверное движение и репозиторий "замер" на 2 часа. Это уже сам по себе было настолько узкое место, что можно отнести к факап как есть.
Я знаю что они использовали старый софт, не знаю как сейчас.

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

V>>у любого vcs есть ремоут сервер, что ты придуриваешься?
·>У git нет сервера, если бы ты читал хотя бы то, что я тебе пишу, то давно бы понял что заблуждаешься.
Я ничего и не говорил про гит, я писал про то, что чтобы закоммитить что-то удалённо в общую репу — нужен сервер.

V>Можно иметь как сервер так называемый repository​ manager, который позволяет организовать множество репов для разных проектов, раздать права доступа, интегрировать с системой автобилдов, ревью, етс. Например, github.
т.е. сервер всё-таки есть?

·>Но в обсуждаемом тут сценарии "бэкап поломаных промежуточных изменений" сервер не нужен, можно самому создать ещё один репо и использовать его в личных целях.
И потереть его, ага

V>>Только интерес? И это всё?
·>У тебя опять проблема с пониманием.
У тебя проблема с интерпретацией фактов. Вымысел выдаёшь за реальность.

V>>Гугл собрал из открытых источников а не закрытых.
·>Думаю из поисковых данных, что вообще-то закрытый источник, открытый только гуглу.
Каким образом масса закрытых серверов по миру отдаст что-то гуглу, если гугел даже не знает где искать? Перебор всех ip и портов?

·>А ты сам посмотрел эти ссылки?
·>

Boost is moving from Subversion centralized version control to Git distributed modular version control.

И? Как это опровергает что и там и там есть?

·>Зачем ты мне доказываешь, что ты не прав? Я это и так знаю.
Зачем ты опять в лужу сел?

V>>Лучше уж нафик нафик этот лесапет.
·>Ну продолжай грызть свой кактус
Кактус грызут те, кому надо массу команд и ключей в гите помнить, а также порядок массы рюшечношашечных операций, чтобы ничего вдруг не поломать/потерять.

V>>Зачем, останутся каждый на своих vcs гораздо более привычных и простых.
·>Не в этой вселенной.
Не в твой вселенной.

V>>А что, у гита есть, к примеру, такая простая фича как шелвинг чтобы на него переходить? Даже свн её собирается ввести ибо поняли её полезность и эффективность.
·>Конечно, всегда была. "git stash" называется, и если тебе интересно внутреннее устройство, то реализована с помощью тех же бранчей.
https://git-scm.com/docs/git-stash
Что то по количеству команд и ключей ни разу не напоминает два простых действия: положить и взять.
Вот сравни:

git:

git stash list [<options>]
git stash show [<stash>]
git stash drop [-q|--quiet] [<stash>]
git stash ( pop | apply ) [--index] [-q|--quiet] [<stash>]
git stash branch <branchname> [<stash>]
git stash [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
         [-u|--include-untracked] [-a|--all] [<message>]]
git stash clear
git stash create [<message>]
git stash store [-m|--message <message>] [-q|--quiet] <commit>

perforce:

p4 [g-opts] shelve [-p] [file ...]
p4 [g-opts] shelve [-a option] [-p] -i [-f | -r]
p4 [g-opts] shelve [-a option] [-p] -r -c change
p4 [g-opts] shelve [-a option] [-p] -c change [-f] [file ...]
p4 [g-opts] shelve -d -c change [-f] [file ...]
p4 [g-opts] unshelve -s shelvedchange [-f -n] [-c change] [-b branch | -S stream [-P stream]] [file ...]

2 команды у perforce и 9 у гита.
Что ты там про кактус говорил?

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

V>·>У git нет сервера, если бы ты читал хотя бы то, что я тебе пишу, то давно бы понял что заблуждаешься.
V>Я ничего и не говорил про гит, я писал про то, что чтобы закоммитить что-то удалённо в общую репу
Причём тут общая репа? Мы вроде о приватой рассуждали.

V> — нужен сервер.
Не "нужен сервер", а "может быть сервер". Линус одно время получал коммиты через емейл.

V>>Можно иметь как сервер так называемый repository​ manager, который позволяет организовать множество репов для разных проектов, раздать права доступа, интегрировать с системой автобилдов, ревью, етс. Например, github.
V>т.е. сервер всё-таки есть?
Может есть, а может и нет. Опционально.

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

V>>>Гугл собрал из открытых источников а не закрытых.
V>·>Думаю из поисковых данных, что вообще-то закрытый источник, открытый только гуглу.
V>Каким образом масса закрытых серверов по миру отдаст что-то гуглу, если гугел даже не знает где искать? Перебор всех ip и портов?
Опять сервера какие-то... Отдаст что?

V>·>А ты сам посмотрел эти ссылки?
V>·>

Boost is moving from Subversion centralized version control to Git distributed modular version control.

V>И? Как это опровергает что и там и там есть?
Я не говорю, что опровергает, я говорю, что это доказывает мой тезис, что с великого и прекрасного svn все бегут на этот жуткий ужасный git; дохнет твой любимый svn.

V>>>Лучше уж нафик нафик этот лесапет.
V>·>Ну продолжай грызть свой кактус
V>Кактус грызут те, кому надо массу команд и ключей в гите помнить, а также порядок массы рюшечношашечных операций, чтобы ничего вдруг не поломать/потерять.
Потому что git предоставляет возможности, а не диктует одно "единственно верное" решение.

V>Вот сравни:
V>2 команды у perforce и 9 у гита.
V>Что ты там про кактус говорил?
И что ты своим невежеством пытаешься доказать?

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

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

V>> — нужен сервер.
·>Не "нужен сервер", а "может быть сервер".
Не может быть а нужен почти всегда, ибо центральное хранилище. Хватит уже сказки про эфемерную распределённость в вакууме рассказывать.

·>Линус одно время получал коммиты через емейл.
Ну можно ещё вручную мержить, но что-то тебе оно не удобно вышло

Автор: ·
Дата: 10.04.17

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

V>>>Можно иметь как сервер так называемый repository​ manager, который позволяет организовать множество репов для разных проектов, раздать права доступа, интегрировать с системой автобилдов, ревью, етс. Например, github.
V>>т.е. сервер всё-таки есть?
·>Может есть, а может и нет. Опционально.
Когда народу больше становится, то абсолютно необходимо. А это как правило всегда.

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

V>>·>Думаю из поисковых данных, что вообще-то закрытый источник, открытый только гуглу.
V>>Каким образом масса закрытых серверов по миру отдаст что-то гуглу, если гугел даже не знает где искать? Перебор всех ip и портов?
·>Опять сервера какие-то... Отдаст что?
Статистика как собирается? Как гугл узнает про сервер если у него нет домена? А если внутри сети? А если VPN? Дальше объяснять?

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

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

V>>Что ты там про кактус говорил?
·>И что ты своим невежеством пытаешься доказать?
Опять в лужу сел?

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

V_>>Я лично имел дело с синхронизацией Perforce в EA между двумя удаленными командами. Одно неверное движение и репозиторий "замер" на 2 часа. Это уже сам по себе было настолько узкое место, что можно отнести к факап как есть.
V>Я знаю что они использовали старый софт, не знаю как сейчас.

Использовали клиент чутьб старее. P4C вместо P4V ЕМНИП

А ситуация с узким местом была не из-за клиента.

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

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

V>>> — нужен сервер.
V>·>Не "нужен сервер", а "может быть сервер".
V>Не может быть а нужен почти всегда, ибо центральное хранилище. Хватит уже сказки про эфемерную распределённость в вакууме рассказывать.
Он нужен если ты хочешь централизованный code review, авто-билды и прочее. Т.е. не для бэкапов.

V>·>Линус одно время получал коммиты через емейл.
V>Ну можно ещё вручную мержить, но что-то тебе оно не удобно вышло

Автор: ·
Дата: 10.04.17

. А коммиты через мыло мержить это ни в раз удобно, ага, не говоря уже о том, что любой коммит это транзакция с кучей препятствий и откатов. Так и вижу замыленных юзеров от этого способа.
А ты пробовал? Ничего сложного, мало чем отличается от работы с "централизованным" сервером. Ознакомься с "git send-mail"/"git am".

V>>>т.е. сервер всё-таки есть?
V>·>Может есть, а может и нет. Опционально.
V>Когда народу больше становится, то абсолютно необходимо. А это как правило всегда.
Не абсолютно и обходимо.

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

V>>>Каким образом масса закрытых серверов по миру отдаст что-то гуглу, если гугел даже не знает где искать? Перебор всех ip и портов?
V>·>Опять сервера какие-то... Отдаст что?
V>Статистика как собирается?
По поисковым запросам и информации на форумах, блогах, статьях, етс.

V>>>И? Как это опровергает что и там и там есть?
V>·>Я не говорю, что опровергает, я говорю, что это доказывает мой тезис, что с великого и прекрасного svn все бегут на этот жуткий ужасный git; дохнет твой любимый svn.
V>Ничего подобного не наблюдаю. Ты выдаешь свои фантазии за действительность.
А это что по-твоему: "Boost is moving from Subversion centralized version control to Git"?

V>>>Кактус грызут те, кому надо массу команд и ключей в гите помнить, а также порядок массы рюшечношашечных операций, чтобы ничего вдруг не поломать/потерять.
V>·>Потому что git предоставляет возможности, а не диктует одно "единственно верное" решение.
V>Дооо. Эти возможности и до гита можно было сделать, половина что-то нафик не сдалась.
Многим — сдалась, поэтому svn и помирает.

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

V_>А ситуация с узким местом была не из-за клиента.
А из-за чего? Причём тут перфорс тогда?

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

V>А из-за чего? Причём тут перфорс тогда?

Общий удаленный P4 сервер, 5 ткм между офисами (LA-Монреаль)

Много файлов. Заметная latency. P4 нужно постоянное соединение с сервером. Если кто-то ошибся и сделал checkout на большом каталоге (директории), то чтобы вернуть в "обратный зад" требовалось еще пару часов

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

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

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

V>>Ну можно ещё вручную мержить, но что-то тебе оно не удобно вышло

Автор: ·
Дата: 10.04.17

. А коммиты через мыло мержить это ни в раз удобно, ага, не говоря уже о том, что любой коммит это транзакция с кучей препятствий и откатов. Так и вижу замыленных юзеров от этого способа.
·>А ты пробовал? Ничего сложного, мало чем отличается от работы с "централизованным" сервером. Ознакомься с "git send-mail"/"git am".
Так как на счёт транзакций, сам будешь ресолвить и мержить? Кто коллизии будет разрешать, тоже git send-mail или человек?

V>>Когда народу больше становится, то абсолютно необходимо. А это как правило всегда.
·>Не абсолютно и обходимо.
Пример?

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

V>>Статистика как собирается?
·>По поисковым запросам и информации на форумах, блогах, статьях, етс.
Это открытая инфа. Кто тебе в бложек про закрытый серв то напишет?

V>>Ничего подобного не наблюдаю. Ты выдаешь свои фантазии за действительность.
·>А это что по-твоему: "Boost is moving from Subversion centralized version control to Git"?
Чем это доказывает, к примеру, что они отказываются от svn?

V>>Дооо. Эти возможности и до гита можно было сделать, половина что-то нафик не сдалась.
·>Многим — сдалась, поэтому svn и помирает.
Ты мне напоминаешь сектантов Илона Маска.

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

V>>А из-за чего? Причём тут перфорс тогда?
V_>Общий удаленный P4 сервер, 5 ткм между офисами (LA-Монреаль)
V_>Много файлов. Заметная latency. P4 нужно постоянное соединение с сервером. Если кто-то ошибся и сделал checkout на большом каталоге (директории), то чтобы вернуть в "обратный зад" требовалось еще пару часов
Выделенное не понял. Человек специально скачал корень на несколько гигов, а потом возмущался что не то скачал? И качал по-новой? А переместить вручную поддиректорию куда надо и туда сделать синк не судьба была? Просто выбор правильной ветки лежит исключительно на пользователе, причём здесь перфорс?

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


V_>>Общий удаленный P4 сервер, 5 ткм между офисами (LA-Монреаль)
V_>>Много файлов. Заметная latency. P4 нужно постоянное соединение с сервером. Если кто-то ошибся и сделал checkout на большом каталоге (директории), то чтобы вернуть в "обратный зад" требовалось еще пару часов
V>Выделенное не понял. Человек специально скачал корень на несколько гигов, а потом возмущался что не то скачал? И качал по-новой? А переместить вручную поддиректорию куда надо и туда сделать синк не судьба была? Просто выбор правильной ветки лежит исключительно на пользователе, причём здесь перфорс?

Один нечаянно сделал checkout каталога по ошибке. А undo checkout — долго, если сервер далеко. N файлов * latency

Никто больше checkout внутри этого каталога сделать не может, пока checkout не будет отменен.

По моему, так, с поправкой на 2011 год. Терминологию точно не помню — вроде checkout. Это когда сообщаешь серверу, "сейчас буду редактировать этот файл/каталог". А сервер снимает его read only и можно редактировать
Я в 13-м все свои "домашние" репозитории перевел на git и больше не сталкивался (== успешно забыл). До этого использовал Perforce в т.ч. и для себя

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

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

V>>>Не может быть а нужен почти всегда, ибо центральное хранилище. Хватит уже сказки про эфемерную распределённость в вакууме рассказывать.
V>·>Он нужен если ты хочешь централизованный code review, авто-билды и прочее. Т.е. не для бэкапов.
V>А коммитить и брать удалённо ты как собрался?
В гите коммит _всегда_ происходит в локальном репо. Брать удалённо — так же, используя любой механизм обмена с ремотами.

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

V>>>Ну можно ещё вручную мержить, но что-то тебе оно не удобно вышло

Автор: ·
Дата: 10.04.17

. А коммиты через мыло мержить это ни в раз удобно, ага, не говоря уже о том, что любой коммит это транзакция с кучей препятствий и откатов. Так и вижу замыленных юзеров от этого способа.
V>·>А ты пробовал? Ничего сложного, мало чем отличается от работы с "централизованным" сервером. Ознакомься с "git send-mail"/"git am".
V>Так как на счёт транзакций, сам будешь ресолвить и мержить? Кто коллизии будет разрешать, тоже git send-mail или человек?
Точно так же как и с обычными ветками.
send-mail/am это лишь один из видов транспорта коммитов. А ещё есть "git bundle", ну и традиционный push/fetch.

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

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

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

V>>>Ничего подобного не наблюдаю. Ты выдаешь свои фантазии за действительность.
V>·>А это что по-твоему: "Boost is moving from Subversion centralized version control to Git"?
V>Чем это доказывает, к примеру, что они отказываются от svn?
А что по-твоему означает слово "moving"?

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

V>>Выделенное не понял. Человек специально скачал корень на несколько гигов, а потом возмущался что не то скачал? И качал по-новой? А переместить вручную поддиректорию куда надо и туда сделать синк не судьба была? Просто выбор правильной ветки лежит исключительно на пользователе, причём здесь перфорс?
V_>Один нечаянно сделал checkout каталога по ошибке. А undo checkout — долго, если сервер далеко. N файлов * latency
V_>Никто больше checkout внутри этого каталога сделать не может, пока checkout не будет отменен.
V_>По моему, так, с поправкой на 2011 год. Терминологию точно не помню — вроде checkout. Это когда сообщаешь серверу, "сейчас буду редактировать этот файл/каталог". А сервер снимает его read only и можно редактировать
V_>Я в 13-м все свои "домашние" репозитории перевел на git и больше не сталкивался (== успешно забыл). До этого использовал Perforce в т.ч. и для себя
Как это не может? Я сомневаюсь что у перфорса нельзя одновременно читать из базы, да ещё в 2011 году. Может, всё-таки, кто-то лок сделал? Тогда да, там включается эксклюзивный доступ.