Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Доступна система управления версиями Apache Subversion 1.15.0"	+/–
Сообщение от opennews (??), 25-Сен-26, 14:01
Спустя более шести лет с прошлого значительного выпуска организация Apache Software Foundation опубликовала релиз централизованной системы управления версиями Subversion 1.15.0... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=66342
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 25-Сен-26, 14:01	+/–
CVS лучше.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14, #16, #38

2. Сообщение от Аноним123 (?), 25-Сен-26, 14:06	+6 +/–
Её ещё использую (да и централизованные VCS в целом)? Эпоха git же, не?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #11, #19, #35

3. Сообщение от Аноним (149), 25-Сен-26, 14:17	–1 +/–
Настоящие программисты Git не используют.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #7, #10

4. Сообщение от Аноним (4), 25-Сен-26, 14:22	+5 +/–
Ага, настоящие пограмисты хранят распечатки на бумаге ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #6, #8, #27

5. Сообщение от Аноним (5), 25-Сен-26, 14:24    Скрыто ботом-модератором	–8 +/–
> Её ещё использую (да и централизованные VCS в целом)? Эпоха git же, > не? Нет, конечно, но местные уникумы все равно наставят тебе минусов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

6. Сообщение от Аноним (6), 25-Сен-26, 14:42	+1 +/–
> на бумаге пропустили - туалетной
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

7. Сообщение от Гуманоид (?), 25-Сен-26, 14:50	–2 +/–
Git - это сильно раздутая консольная утилита для работы с гитхабом. Для работы есть более вменяемые инструменты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #9

8. Сообщение от Аноним (8), 25-Сен-26, 14:50	+/–
потому что настоящие программисты пишут сразу настоящий продукт. без версий, без истории написания
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

9. Сообщение от Аноним (8), 25-Сен-26, 14:52	+/–
любая утилита для работы с дутым хабом будет сама по себе раздутой
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

10. Сообщение от Аноним10084 и 1008465039 (?), 25-Сен-26, 14:52	–1 +/–
Вместо этого они используют BitKeeper :) Это просто у одного финского в-то-время-нестудента не хватило денег на лицензию, вот он и накостылял на коленке git
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #25, #96

11. Сообщение от Аноним (11), 25-Сен-26, 14:54	–5 +/–
> Её ещё использую (да и централизованные VCS в целом)? Эпоха git же, > не? VCS и git разные вещи git это система обмена изменениями, почитайте на досуге какую проблему решал Линус когда писал его. Это как лопата и совок, просто модно молодежно вот и побежали использовать понятия не имея для чего оно. Ну в последствии дорабатывали git чтоб хоть как то сделать пригодным для работы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #15, #52

12. Сообщение от Метрика (?), 25-Сен-26, 15:02	+3 +/–
Учитывая каким монстром стал git, на его фоне svn выглядит очень даже ничего
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17, #18

14. Сообщение от Аноним (14), 25-Сен-26, 15:15	+1 +/–
Выглядит как вброс, но на деле 20 лет назад когда CVS меняли на SVN, потеряли возможность быстро синкаться с локального зеркала репозитория. Интернет был плохой, и не иметь возможности закоммитить или лог посмотреть когда нужно - это был прям зашквар, и если cvs можно было просто указать другой сервер, svn такого не полволял, а переключение между апстримами там сделано через такую задницу что и вспоминать не хочется (но никогда не забуду что там есть команды `switch`, `rebase` и `switch --rebase`, и поди ты разберись какая для этого). В общем, по итогу оказалось что и когда cvs использовали, и когда svn, нам просто был нужен git - с ним все эти проблемы забылись как страшный сон.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #127

15. Сообщение от Аноним (14), 25-Сен-26, 15:22	+1 +/–
> VCS и git разные вещи Докажи. > git это система обмена изменениями, почитайте на досуге какую проблему решал Линус когда писал его О, начался спор на уровне какую задачу решал Линус 20 лет назад. > просто модно молодежно вот и побежали использовать понятия не имея для чего оно Прям за всех говорить будешь? А ничего что люди наелись централизованным г-ном не работающим толком оффлайн, и DVCS была как глоток свежего воздуха? А с svn наелись ещё и тормозов, огромных чекаутов и отсутствия полноценных веток и тегов. И было бы это модно молодёжно, хайп бы уже прошёл, однако что-то на SVN никто не вернулся. Используют только для нишевых кейсов где его минусы становятся плюсами, как-то версионирование ассетов. > Ну в последствии дорабатывали git чтоб хоть как то сделать пригодным для работы. Ага, svn тоже, причём последний так и не доработали (см. выше про синк из локального клона).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #20

16. Сообщение от Аноним (16), 25-Сен-26, 15:26	+1 +/–
застал cvs в начале нулевых, помню жалел после перехода на svn о потере возможности задавать периоды вида "week ago" и подобные человекочитаемые темы. Для людей делалось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #45

17. Сообщение от Аноним (14), 25-Сен-26, 15:27	–1 +/–
И каким же монстром он стал? Так-то svn тяжелее SIZE (subversion-1.14.5.tar.bz2) = 8675355 SIZE (git-2.55.0.tar.xz) = 8177180 при том что тащит за собой ещё и апачевскую помойкобиблиотеку apr, и даже в https не умеет без внешней библиотеки (ещё один костыль serf).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #24

18. Сообщение от fatlortroll (?), 25-Сен-26, 15:28	+/–
Fossil-же, ну!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #37

19. Сообщение от Аноним (19), 25-Сен-26, 15:29	+1 +/–
По-прежнему отличный вариант для *централизованной* VCS. Это если вы понимаете разницу. А если не понимаете - то и сидите на git.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #21, #31

20. Сообщение от Аноним (11), 25-Сен-26, 15:35	–3 +/–
классические - централизованные, git распределенный, потом когда git стали использовать как VCS понадобился централизованный обзор изменений - сделали githab и аналоги. нет смысла спорить с реальностью, не делайте так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #30, #111

21. Сообщение от Аноним10084 и 1008465039 (?), 25-Сен-26, 15:37	+5 +/–
Вот только смысл в строго централизованной VCS, если git абсолютно так же можно использовать квазицентрализованно? Зато если вдруг понадобиться децентрализация, она сразу будет из коробки. Просто реально интересно узнать, какие, пусть специфические, фичи может даже svn по сравнению с git?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #106, #145

22. Сообщение от Вася Пупкин (?), 25-Сен-26, 15:44	–4 +/–
Зачем это устаревшая система контроля версий, если есть Git ?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23, #29, #34, #62

23. Сообщение от Пыщь (?), 25-Сен-26, 15:50	+4 +/–
"Больше всего я жалею не о деньгах, а о том, что Git — это просто жалкое подобие SCM. Меня сводит с ума, что его модель представляет собой сервер с тарболами. Даже Линус признал мне, что это дерьмовый дизайн. Он делает так, как считает нужным, — но это вовсе не значит, что весь мир должен считать так же." (кажется, цитата)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

24. Сообщение от Аноним (24), 25-Сен-26, 15:52	–1 +/–
Так там ещё полноценный сервак есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #32

25. Сообщение от Аноним (25), 25-Сен-26, 15:52	+3 +/–
И ъорошо, что не хватило. В результате, теперь все могут свободно и бесплатно пользоваться Git.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #36

27. Сообщение от Оно ним (?), 25-Сен-26, 16:20	+/–
https://semicolon.trm.sh/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

29. Сообщение от xsignal (ok), 25-Сен-26, 16:27	–1 +/–
Git нужен только для проектов, типа ядра Linux, а использовать его в небольших и средних проектах с малым числом разработчиков - это стрелять из пушки по воробьям - избыточно, неудобно, сложно, а svn здесь - самое то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #33, #81

30. Сообщение от Аноним (14), 25-Сен-26, 16:49	+2 +/–
Я спорю не с реальностью, а спорю с безграмотными заявлениями. Но с этим спорить не буду, тут просто набор слов. Централизованность/распределённость - это просто свойства VCS, тут не надо ничего противопоставлять. А вебмордочки вообще типу VCS ортогональны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

31. Сообщение от Аноним (14), 25-Сен-26, 16:50	+/–
Так git можно использовать централизованно, никакого требования именно централизованной VCS нет и никогда не было. Есть конкретные требования некоторых свойств которые CVCS исторически обеспечивают лучше, типа отдать кусок репозитория или не отдавать всю историю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #42

32. Сообщение от Аноним (14), 25-Сен-26, 16:51	+/–
Сервак везде есть, и весит он копейки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #54

33. Сообщение от Аноним (14), 25-Сен-26, 16:59	–1 +/–
> стрелять из пушки по воробьям - избыточно, неудобно, сложно, а svn здесь - самое то. Очень странные мысли, вы видимо VCS никогда не пользовались, и проекты не разрабатывали. Как раз для небольших проектов git сильно легче и удобнее, потому что git init и можно коммитить. Никаких svnadmin, никаких выделенных серверов под репозиторий, никаких проблем если локально созданный репозиторий вдруг захотелось куда-то выложить (при этом что сейчас и некуда). И в чём избыточность? Функциональность которой вы не пользуетесь не жрёт ни CPU, ни места на диске, ни токенов, ни ваших нейронных связей, а когда она понадобится, она у вас будет, и не надо будет конвертить репозиторий из древнего централизованного недоразумения в полноценную vcs.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #71

34. Сообщение от Аноним (14), 25-Сен-26, 17:02	+/–
Прежде всего для заброшенного легаси, которое в git конвертить уже некому и незачем, но исходники достать нужно. В редких случаях для специфичных кейсов типа версионирования 3D ассетов (текстур, сцен, моделей), хотя наверняка для этого есть более подходящие инструменты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

35. Сообщение от Сладкая булочка (?), 25-Сен-26, 17:03	–1 +/–
git не тянет большие размеры репозиториев.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #39, #40

36. Сообщение от Сладкая булочка (?), 25-Сен-26, 17:04	+/–
Делаем вывод: фину не надо платить)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #94

37. Сообщение от Аноним (14), 25-Сен-26, 17:05	–1 +/–
Интересно что человек, в мирке которого git "стал монстром" и вообще тяжелее svn, скажет о поделке со встроенными сайтом, issue трекером, рьвьюшницей, вики, базой данных и ещё бог весть чем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

38. Сообщение от Аноним (38), 25-Сен-26, 17:12	+4 +/–
RCS лусше CVS. А Новая папка (14) лучше их всех вместе взятых.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #110, #149

39. Сообщение от Аноним (14), 25-Сен-26, 17:15	+/–
В чём именно это выражается? Помню миграцию FreeBSD с svn на git - там git клон (чекаут + вся история) весил меньше чем svn (только чекаут одной ревизии), сам клон выполнялся на порядок быстрее (во многом за счёт меньшего насилия над диском), а операции над ним (коммит, смена ветки, лог, блейм) выполнялись мгновенно, а не минутами как в svn. svn технически может "тянуть" что-то лучше только в одном случае - когда ты чекаутишь небольшой кусочек репозитория. Честно говоря, даже не знаю репозиториев где кусочек без целого будет представлять какой-то интерес, но допускаю что такое бывает. Есть огромные репозитории которые git действительно "не потянет", типа монореп гугла или микрослопа. Но svn "не потянет" даже 1/100 от них, там для работы используются виртуальные файловые системы подрягивающие контент on-demand. Но cli к ним всё равно повторяет git, в ms по крайней мере.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #44, #50, #61

40. Сообщение от Аноним (38), 25-Сен-26, 17:15	+/–
Большие -- это сколько в байтах? Майкрософт и Гугл знают об этом? (Я знаю, что знают, но вот с какого размера начинаются неудобства тут знает приблизительно никто, потому что ни у кого здесь столько кода нет).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #43, #49, #107

41. Сообщение от Аноним (45), 25-Сен-26, 17:21	+/–
Когда они уже поддержат работу с Git? А то как-то не честно, git-svn есть, а svn-git нету
Ответить | Правка | Наверх | Cообщить модератору

42. Сообщение от Аноним (45), 25-Сен-26, 17:28	–2 +/–
Может чел просто любит страдать в духе "я залочу этот файл чтобы никто в команде работать не мог и свалю в закат, а ещё у меня регулярно не работает Инет, поэтому разлочить я его смогу когда-нить потом, если раньше не отправят на фарш"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

43. Сообщение от Аноним (44), 25-Сен-26, 17:29	+1 +/–
докачки до сих пор нет. Если git pull отвалился, то качай заново.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

44. Сообщение от Аноним (44), 25-Сен-26, 17:31	–1 +/–
Для полноценной работы гиту надо качнуть всю репу со всей историей. Дедубликация тоже посредственная. Если в репе много бинарей, то она раздувается. Частично спасают всякие костыли, вроде pristine-lfs.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #51, #103

45. Сообщение от Аноним (45), 25-Сен-26, 17:35	+/–
это что-то типа git checkout "head@{1 week ago}" ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

47. Сообщение от вах (ok), 25-Сен-26, 17:45	+/–
Теперь новые версии можно выпускать каждый час!
Ответить | Правка | Наверх | Cообщить модератору

49. Сообщение от Сладкая булочка (?), 25-Сен-26, 18:19	+/–
> Большие -- это сколько в байтах? Майкрософт и Гугл знают об этом? На 10Гб уже плохо. У Гугла свой монорепозиторий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #56

50. Сообщение от Сладкая булочка (?), 25-Сен-26, 18:22	+1 +/–
> В чём именно это выражается? Помню миграцию FreeBSD с svn на git > - там git клон (чекаут + вся история) весил меньше чем > svn (только чекаут одной ревизии), сам клон выполнялся на порядок быстрее > (во многом за счёт меньшего насилия над диском), а операции над > ним (коммит, смена ветки, лог, блейм) выполнялись мгновенно, а не минутами > как в svn. Монорепы больше 10Гб. > svn технически может "тянуть" что-то лучше только в одном случае - когда > ты чекаутишь небольшой кусочек репозитория. Честно говоря, даже не знаю репозиториев > где кусочек без целого будет представлять какой-то интерес, но допускаю что > такое бывает. В монорепах такое часто нужно. Скажем твоему проекту нужны только определенные библиотеки. > Есть огромные репозитории которые git действительно "не потянет", типа монореп гугла или > микрослопа. Но svn "не потянет" даже 1/100 от них, git'у плохо уже на 10Гб, svn прекрасно тянет. > там для работы используются виртуальные файловые системы подрягивающие контент on-demand. Но cli к ним всё равно повторяет git, в ms по крайней мере. Утиная типизация тут неприменима. Это не git.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #55

51. Сообщение от Аноним (14), 25-Сен-26, 18:23	+/–
Репозитории больших размеров, про которые изначально шла речь != репозитории с бинарными блобами. Репозитории больших размеров git тянет замечательно, я про это расписал. А блобы у которых между ревизиями меняется чуть более чем всё (а почти все блобы такие), не задедуплицирует вообще ничто. Всю историю git может не тянуть, итого из кейсов которые git "не тянет" остаётся только когда нужно вытянуть кусочек репы, и да - это решается отдельными инструментами, равно как и с svn, который тоже не умеет виртуальную файловую систему из коробки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #53

52. Сообщение от пох.. (?), 25-Сен-26, 18:33	+/–
> git это система обмена изменениями, почитайте на досуге какую проблему решал Линус когда > писал его. Он никакую проблему не решал. Его как раз устраивала "новая папка 1.2.32" Проблемы были не у Линуса, а у тех, других васянов - которым предлагалось порезать помельче и перепослать в рассылку, а они-то тогда пользовались cvs/svn, чтобы понимать кто из них чего наменял и где. Потому что других способов работы с кодом - Линус не знал и знать не хотел. И его поделка автоматизирует именно этот, никому на свете кроме него ненужный workflow.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #73

53. Сообщение от Аноним (44), 25-Сен-26, 18:43	+2 +/–
>это решается отдельными инструментами, равно как и с svn Это какими же, интересно? svn checkout после обрыва спокойно докачивается через svn update. git это как не умел, так и не умеет. >про которые изначально шла речь != репозитории с бинарными блобами Они и становятся большими по причине, что оно не умеет работать с блобами > Репозитории больших размеров git тянет замечательно, я про это расписал При обрыве качает всё сначала. Это называется "не тянет". Если репа по 500мб, то готовь гигабитный интернет. Иначе оно не умеет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #58

54. Сообщение от Аноним (44), 25-Сен-26, 18:44	+/–
В гите его нет. Работает поверх ssh
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #82

55. Сообщение от Аноним (14), 25-Сен-26, 18:58	+/–
> Монорепы больше 10Гб. Ну репы в 20Гб у меня есть, там базовые операции типа commit/checkout/log происходят мгновенно. Вот rebase сотни коммитов может десяток секунд занимать, это да. Посмотрел бы я что в svn c этим было, когда switch на 3G репозитории (опять же реальный опыт - freebsd ports) занимал час, а update за пару недель - минут 5. > В монорепах такое часто нужно. Скажем твоему проекту нужны только определенные библиотеки. Да, и это решается не svn, а виртуальными ФС. Как arc в yandex, и забыл как называется похожая штука в ms, недавно про неё доклад был как какой-то большой конфе. Потому что реальная фс не знает какие файлы ты трогал (поэтом commit в корне монорепы нахолодную потребует обойти всё дерево фс), и не умеет тянуть по сети только то что ты пытаешь прочитать, а виртуальная - запросто. А бэкендом там уже будет распределённое хранилище любых размеров с кучей индексов на порядок сложнее git'ового. > git'у плохо уже на 10Гб, svn прекрасно тянет Что значит "плохо", давай конкретнее. Разные операции трогают разные объёмы данных, что-то вообще от vcs не зависит - например, когда нужно обойти всё дерево рабочей директории на файловой системе на предмет изменений, это всегда медленно. `git gc --aggressive` перелопатит весь реп, при этом у `git commit <filename>` сложность - O(глубина файла в иерархии + макс число записей в любом из родительских каталогах), что для адекватно организованного репозитория любого размера - константа, и он мгновенный даже на терабайтной репе на HDD. Есть передача по сети, но как я уже говорил, svn ухитряется делать чекаут одной ревизии дольше чем git всей истории, это факт давно подтверждённый на репозиториях freebsd src и ports. И что характерно, нет таких локальных операций на которых svn был бы быстрее, потому что в качестве хранилища там используется одно из самых тормозных решений которые вообще можно было выбрать. А то что требует похода по сети - это вообще пиши пропало. > Утиная типизация тут неприменима. Это не git. Применима. Все идиомы аналогичные, соответственно и команды, и ключи команд. С яндексовским arc делают просто `alias git=arc`.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #60

56. Сообщение от Аноним (14), 25-Сен-26, 19:04	+/–
У гугла проприетарное поделие под названием perforce, над которым у них своя нашлёпка связанная с билд системой, что позволяет, когда ты хочешь собрать бэкенд например, карт, зачекаутить только то что он по зависимостям требует. Такое ни одна из обычных vcs не осилит, но пользоваться perfoce было адовым адом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #59

57. Сообщение от zionist (ok), 25-Сен-26, 19:43	+2 +/–
Git - это так же централизованная система хранения версий. По крайней мере только централизованно Git и используется. Лишите любой проект доступа к центральному сереверу на GitHub и к его аналогам и проект умрёт.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #67, #68, #72, #86

58. Сообщение от Аноним (14), 25-Сен-26, 20:05	+/–
> Это какими же, интересно? svn checkout после обрыва спокойно докачивается через svn update. git это как не умел, так и не умеет. Я уже сказал, виртуальными фс. > Они и становятся большими по причине, что оно не умеет работать с блобами А с ними никто не умеет работать. Большинство бинарных форматов - сжатые данные, при изменении они жмутся сызнова и общих частей вдоль истории примерно 0 целых 0 сотых. Чтобы с ними нормально работать, нужно либо их не жать (например, хранить растры как bmp, а документы - как несжатый xml), либо нужна специализированная vcs под этот тип данных (например, картинки), либо забить на это и грузить ревизии файлов on-demand. Первое никто не делает, второе делают очень редко, третье я как раз и упомянул. svn это не умеет, git умеет в виде lfs расширения. А так-то, открою секрет, только с блобами git и умеет работать - в отличие от недоvcs хранящих патчи и тормозящих их накладывая, git хранит целиком версии, и delta-кодирует их. Поэтому ему всё равно что внутри - текст или bmp, если есть бинарные общие части они сожмутся. Если нет - нет. Никто лучше не умеет. > При обрыве качает всё сначала. Это называется "не тянет". Если репа по 500мб, то готовь гигабитный интернет. Иначе оно не умеет. А, ну это называется аргументов не осталось. Ладно лет 15 назад когда svn УЖЕ закопали, это ещё можно было принять, но сейчас... Да, 500мб репу по модему не скачает, расходимся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #64, #113

59. Сообщение от Сладкая булочка (?), 25-Сен-26, 20:24	+/–
> У гугла проприетарное поделие под названием perforce, над которым у них своя > нашлёпка связанная с билд системой, что позволяет, когда ты хочешь собрать > бэкенд например, карт, зачекаутить только то что он по зависимостям требует. > Такое ни одна из обычных vcs не осилит, но пользоваться perfoce > было адовым адом. Они вроде им с 15 года не пользуются? Посыл один: большие монорепы git не выдерживает, поэтому у всех свои костыли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #66, #77

60. Сообщение от Сладкая булочка (?), 25-Сен-26, 20:49	+/–
>> Монорепы больше 10Гб. > Ну репы в 20Гб у меня есть, там базовые операции типа commit/checkout/log > происходят мгновенно. Вот rebase сотни коммитов может десяток секунд занимать, это > да. Посмотрел бы я что в svn c этим было, когда > switch на 3G репозитории (опять же реальный опыт - freebsd ports) > занимал час, а update за пару недель - минут 5. Есть мнение, что ветками в svn пользоваться не надо. >> В монорепах такое часто нужно. Скажем твоему проекту нужны только определенные библиотеки. > Да, и это решается не svn, а виртуальными ФС. Как arc в > yandex, и забыл как называется похожая штука в ms, недавно про > неё доклад был как какой-то большой конфе. Потому что реальная фс > не знает какие файлы ты трогал (поэтом commit в корне монорепы > нахолодную потребует обойти всё дерево фс), и не умеет тянуть по > сети только то что ты пытаешь прочитать, а виртуальная - запросто. > А бэкендом там уже будет распределённое хранилище любых размеров с кучей > индексов на порядок сложнее git'ового. В svn ты можешь счекаутить только нужную директорию с проектом последней ревизии, что будет скажем 100 Мб, а не весь чекаут в 30 Гб. Про полный git clone можно вообще умолчать. >[оверквотинг удален] > commit <filename>` сложность - O(глубина файла в иерархии + макс число > записей в любом из родительских каталогах), что для адекватно организованного репозитория > любого размера - константа, и он мгновенный даже на терабайтной репе > на HDD. Есть передача по сети, но как я уже говорил, > svn ухитряется делать чекаут одной ревизии дольше чем git всей истории, > это факт давно подтверждённый на репозиториях freebsd src и ports. И > что характерно, нет таких локальных операций на которых svn был бы > быстрее, потому что в качестве хранилища там используется одно из самых > тормозных решений которые вообще можно было выбрать. А то что требует > похода по сети - это вообще пиши пропало. Плохо значит на базовых операциях. clone медленный, status медленный, diff медленный. В svn можно работать только с нужными директориями. >> Утиная типизация тут неприменима. Это не git. > Применима. Все идиомы аналогичные, соответственно и команды, и ключи команд. С яндексовским > arc делают просто `alias git=arc`. Речь не об этом. Это своя система, которую у себя не развернешь. А гит с коробки так не может.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #75, #119

61. Сообщение от Сладкая булочка (?), 25-Сен-26, 21:03	+/–
> Помню миграцию FreeBSD с svn на git Там размеры репозитория скромные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #65

62. Сообщение от tkzv (ok), 25-Сен-26, 21:06	+/–
Для собственных заметок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

64. Сообщение от Аноним (44), 25-Сен-26, 21:33	+/–
>Я уже сказал, виртуальными фс. Какими? Из коробки этого у гита нет. svn же позволяет продолжить с любого места. >Большинство бинарных форматов - сжатые данные, при изменении они жмутся сызнова и общих частей вдоль истории примерно 0 целых 0 сотых Так речь про дедубликацию. Если в разные ветки закинуть одинаковые файлы, то гит будет хранить их два раза. Очень "удобно". >Да, 500мб репу по модему не скачает, расходимся. Да, иногда эта проблема. Причём серьёзная. Плюс нагрузка на сервак, который обязан выдавать репу со всей историей, которая в 99% не нужна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #74

65. Сообщение от Аноним (44), 25-Сен-26, 21:35	+/–
Даже больше. гит там используется в режиме одной ветки. Т.е. по сути работает как svn.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #70

66. Сообщение от Аноним (44), 25-Сен-26, 21:36	+/–
Да, в дебиане например pristine-lfs для хранения тарболов. Но от тоже жуть, какой неудобный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #90

67. Сообщение от Аноним10084 и 1008465039 (?), 25-Сен-26, 21:37	+/–
Социально да, но технически нет. В svn если центральный сервер помрёт, насколько я понимаю, история того. Разве что рабочие копии останутся на руках. А в git у каждого по сути готовая полноценная репа с историей (если выкачивал)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #69

68. Сообщение от Аноним (44), 25-Сен-26, 21:40	+/–
Да, так и есть. Синхронизации между репами без центрального сервера там не предусмотрено.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

69. Сообщение от Аноним (44), 25-Сен-26, 21:42	+/–
svn позволяет коммитить в локальную репу. Сделать синхронизацию не проблема, только никому это не надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #88

70. Сообщение от Сладкая булочка (?), 25-Сен-26, 21:46	+/–
> Даже больше. Полный клон - 1.45 GiB по сети. https://vermaden.wordpress.com/2026/01/10/add-port-to-freebs.../
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #79

71. Сообщение от А ноним (?), 25-Сен-26, 22:01	+1 +/–
Вот только трындеть не надо, свн прекрасно работает без серверов, репа создаётся в указанном месте на локальной ФС, после чего "клиент" svn прекрасно с ней работает в 1 харю. "git через ssh" вощем-то тоже работает сервером (сам git на удалённой репе). При этом искаробки там разделение доступа вообще не предусмотрено (несмотря на ssh), и для разделения доступа безусловно нужны сторонние тулы типа gitolite.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #83

72. Сообщение от Сладкая булочка (?), 25-Сен-26, 22:12	+1 +/–
> Лишите любой проект доступа к центральному сереверу на GitHub и к его аналогам и проект умрёт. Формально нет. Отвалятся баг репорты, пулл реквесты, CI, но код можно с любой копии взять. Но на практике да: хипстеры начнут ныть, что работать невозможно, а локально собрать проект у них лапки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #78, #85

73. Сообщение от Аноним (14), 25-Сен-26, 22:55	+/–
> Потому что других способов работы с кодом - Линус не знал и знать не хотел.   > И его поделка автоматизирует именно этот, никому на свете кроме него ненужный workflow. Время ох**тельных историй. Расскажи-ка, павлин, какие тогда были workflow приёма изменений через review кроме патчей по почте, и какие доступные VCS их умели.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #76

74. Сообщение от Аноним (14), 25-Сен-26, 23:10	–1 +/–
> Какими? Из коробки этого у гита нет. svn же позволяет продолжить с любого места. git-lfs, а для svn ничего похожего нет. Нет, это не про докачку, следи за дискуссией. > Так речь про дедубликацию. Если в разные ветки закинуть одинаковые файлы, то гит будет хранить их два раза. Очень "удобно". Нет, не будет. Ты этой репликой просто расписался в непонимании базовых принципов работы git - он использует контентно-адресуемое хранилище, где содержимое файла адресуется по его хэшу. Ни при каких обстоятельствах один файл, будь он в одном коммите в двух местах дерева, или в разных моментах истории, или в разных ветках, может быть вообще без общего корня, не будет храниться два раза, это физически невозможно. "Эта" дедупликация работает на фундаментальном уровне до дельта-компрессии паков. В последнем случае ещё и "незначительно изменившиеся" блобы начинают занимать O(delta) места. > Да, иногда эта проблема. Причём серьёзная. Согласен. Но только для тех, для кого. Модемщики-любители могут использовать svn, но, во-первых, это не даёт им право заявлять что svn применим в реальном мире, во-вторых, не понятно на чём, когда всё уже в git. > Плюс нагрузка на сервак, который обязан выдавать репу со всей историей, которая в 99% не нужна. Ой, это чушь, тем более что вы уже расписались. Сервак git просто отдаёт pack, это тупо готовый уже сжатый файл, в него даж смотреть не нужно. А вот svn да - там нагрузка, он реально за каждый запрос ворочает базой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #101

75. Сообщение от Аноним (14), 25-Сен-26, 23:20	–1 +/–
> Есть мнение, что ветками в svn пользоваться не надо. Согласен. Это никак не противоречит тому что svn пользоваться не надо. > В svn ты можешь счекаутить только нужную директорию с проектом последней ревизии, что будет скажем 100 Мб, а не весь чекаут в 30 Гб. Про полный git clone можно вообще умолчать. Я знаю, я выше писал уже писал что это чуть ли не единственный кейс где svn имеет смысл. > Плохо значит на базовых операциях. clone медленный, status медленный, diff медленный. В svn можно работать только с нужными директориями. Кроме выше описанного кейса, конечно же нет, на одном и том же скоупе git на порядок быстрее потом что у него гораздо эффективнее устроено хранилище. Возможно ваше заблуждение проистекает из дефолтов в подкаталоге репозитория `svn diff|status` работает только в этом подкаталоге, git же во всём репозитории. `git diff|status .` будет на порядок быстрее svn'а, и можно настроить чтобы ограничение текущим каталогом было дефолтом. > Речь не об этом. Это своя система, которую у себя не развернешь. А гит с коробки так не может. svn тоже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

76. Сообщение от пох.. (?), 25-Сен-26, 23:26	+1 +/–
> Время ох**тельных историй. Расскажи-ка, павлин, какие тогда были workflow приёма изменений > через review кроме патчей по почте спроси у команды разрарботчиков net3, как им удалось обойтись без патчей-по-почте. Или у freebsd team времен Хаббарда. Ни трака еще не было, ни фабрикатора. А большие и сложно взаимосвязанные куски кода умудрялись как-то вот разрабатывать. Как-то вот, удивительно, но... обходились! В почту отправлялась только... почта. Например, нотифай что кто-то закоммитил очередной кусок. Тем более что тогдашняя почта не у всех бы этот кусок вообще переварила. Ну мелкий патч ты мог конечно так кинуть, но для этого гит не нужен, достаточно diff. Вероятнее всего потому, что никакой review миллиона одностраничных патчей, в которые превращается любая мало-мальски сложная подсистема в чудесатом воркфлоу твоего божка, в принципе невозможен, и сводится к замене colour на color и обратно, пока божку не жалуются через личные контакты, доступные только уважаемым людям, и он чохом не аппрувит...ой, снова без ревью "патамушта у нас оказываетцо нет майнтейнера на уровне добавить-новую-фс" и все эти ревьюверы, оказывается, были просто непрошенными советчиками без прав и обязанностей. > и какие доступные VCS их умели. порезать патчи из cvs/svn и отправить в рассылку умели шелловские скрипты строк на 50. Которые и использовались для общения с твоим божком теми кто пользовался vcs для разработки. Проблема что к ревью это никакого отношения не имело, только к поклонению. Очевидно что ты никогда даже и не пытался отслеживать изменения ни в какой части ядра. (мы уже как-то раз убедились что ты даже не знаешь про оооочень специфический инструментарий, который используется для этой цели - гит, как ни изумительно, сам умеет только в одну сторону, а обратную часть божок не осилил. Видимо, его-то вполне устраивал right-click/save-as новаяпапкалинукс1.1.1 - в принципе, если самому никакой код не писать, времени на такое хватает.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #80

77. Сообщение от Аноним (14), 25-Сен-26, 23:28	+/–
> Посыл один: большие монорепы git не выдерживает Нет, посыл не такой. Посыл - большин монорепы не выдерживает ни git ни svn. > поэтому у всех свои костыли. Почему ты употребляешь слово "костыли"? Какое, по-твоему, некостыльное решение работы с репозиторием в 1Тб на 10 миллиардов файлов, если тебе из него нужно 1%, но ты наперёд не знаешь пути, которые нужны?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #93, #109

78. Сообщение от Джон Титор (ok), 25-Сен-26, 23:31	–1 +/–
Я такое реально видел XD. Парни на одном проекте не могли собрать проект имея инструкции, файл CI (yaml) и кучу времени. Почему-то такие люди не благодарны если подсказать очевидные вещи как что и к чему. Особенно если у тебя рабочий титул (или позиция, кто как это называет) пониже чем у них.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

79. Сообщение от Аноним (14), 25-Сен-26, 23:33	+/–
Да не важно, я утверждаю что и с такой репой в svn работать комфортно невозможно, потому что на своей шкуре это испытал пока FreeBSD наконец не переехала на git. Хочешь доказать обратное - выложи git и svn рядом на одном хосте, а мы посмотрим сколько там занимают типовые операции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #99

80. Сообщение от Аноним (14), 25-Сен-26, 23:39	–1 +/–
> спроси у команды разрарботчиков net3, Нет, я спросил у тебя конкретно, но ты начал увиливать. Вопрос-то был риторический, потому что через почту и принимали, и именно в этот воркфлоу целился git. > Проблема что к ревью это никакого отношения не имело, только к поклонению Это твоё поклонение с нами в одной комнате? Павлин, я тебе ещё 5 лет назад, когда ты вандалил OSM, сказал: прекрати пить. Ещё не поздно, потому что сейчас ты несёшь не больший бред чем тогда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #87

81. Сообщение от limafresh (ok), 25-Сен-26, 23:40	–1 +/–
> использовать его в небольших и средних проектах с малым числом разработчиков - это стрелять из пушки по воробьям Ну да, конечно. Поднимать сервер с "удобной" SCV конечно "проще", и наверное не требует специальных навыков и денег на хостинг (нет), чем создать репозиторий на GitHub или подобном сервисе по нажатию кнопки. Зато не git. Странно, что люди не понимают, что SCV - это не программа, которую можно выбирать, а инструмент для загрузки кода в онлайн-сервис, и какая там есть, такая и есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #84

82. Сообщение от Аноним (14), 25-Сен-26, 23:40	–1 +/–
Есть, работает не только поверх ssh. Достаточно запустить и в nginx сделать proxy_pass.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #97

83. Сообщение от Аноним (14), 25-Сен-26, 23:42	–1 +/–
> Вот только трындеть не надо, свн прекрасно работает без серверов, репа создаётся в указанном месте на локальной ФС, после чего "клиент" svn прекрасно с ней работает в 1 харю. Ты хоть читал на что отвечаешь? Я ровно весь процесс создания локального репозитория svn для 1 хари расписал, а также расписал насколько в git он удобнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

84. Сообщение от Аноним (14), 25-Сен-26, 23:44	+2 +/–
> Ну да, конечно. Поднимать сервер с "удобной" SCV конечно "проще", и наверное не требует специальных навыков и денег на хостинг (нет), чем создать репозиторий на GitHub или подобном сервисе по нажатию кнопки Расшифруй аббревиатуру SCV. Дай угадаю, Sistema Controlya Versiy?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #138

85. Сообщение от пох.. (?), 25-Сен-26, 23:44	–1 +/–
>> Лишите любой проект доступа к центральному сереверу на GitHub и к его аналогам и проект умрёт. > Формально нет. Отвалятся баг репорты, пулл реквесты, CI, но код можно с можно. Только это будет - мертвый код. И проблема не в том что начнут какие-то хипстеры, а в том что ты останешься с кодом, который некому сопровождать. А это совсем-совсем не про кое-как суметь собрать в своем хомяке. А от потери целиком базы svn (допустим что у васяна вообще нет бэкапа и самого васяна закрыли за изменку на четвертак) - ну потеряешь ты очень ценную (нет) историю как васян два года искал лишний байт в strncpy, код от этого у тебя-то никуда не денется. Можешь даже им снова поделиться с тем, другим васяном. кстати, наличие у cvs интересного ключика -o как бы намекает, как во времена, когда диски были большими а влезало туда мало, относились к истории. Считать ее самоценной - это вот как раз в svn зачем-то додумались.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #108, #126

86. Сообщение от Аноним (14), 25-Сен-26, 23:48	+/–
> Git - это так же централизованная система хранения версий. По крайней мере только централизованно Git и используется. Нет, git это децентрализованная система хранения версий, а используется централизованно она потому что это удобно. Разумеется, только когда это удобно - в других случаях она используется децентрализовано. > Лишите любой проект доступа к центральному сереверу на GitHub и к его аналогам и проект умрёт. Нет, так будет с svn. А с git достаточно git remote add && git push - и проект на новом центральном сервере. Или расшарить доступ - и проект на своём сервере. Или подтянуть radicle - и проект полностью децентрализован. Но всё ещё в git.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #95, #116

87. Сообщение от пох.. (?), 25-Сен-26, 23:49	+/–
блин, да никто ничего не принимал через почту кроме однострочников. Такой индивидуй был - один. И даже в его же проекте отдельные команды использовали - svn, а не патчи через почту. ты опоздал родиться,но как всегда - врешь, выдавая свои фантазии за знания.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #89

88. Сообщение от Аноним (14), 25-Сен-26, 23:53	+/–
> Сделать синхронизацию не проблема, только никому это не надо. Проблема, причём фундаментально нерешаемая. В svn можно сделать разве что зеркалирование репозитория, так что в него нельзя будет коммитить. И даже это бесполезно, потому что клиент не умеет обновляться из одной репы (например регулярно синхронизируемой локальной копии удалённого репозитория при нестабильном интернете), а коммитить в другую. В git можно коммитить куда угодно, и любую конфигурацию разобщённых репозиториев тривиально синхронизировать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #91

89. Сообщение от Аноним (14), 25-Сен-26, 23:56	+/–
А ничего что ядро уже несколько десятков лет ТОЛЬКО через почту и разрабатывается?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #104

90. Сообщение от пох.. (?), 25-Сен-26, 23:58	+/–
> Да, в дебиане например pristine-lfs для хранения тарболов. Но от тоже жуть, > какой неудобный. потому что это костыль, ломающий собственно смысл vcs - все, что ты туда положил - уже не версионируется, приехали. но (microsoft!) когда-то нешмагла по другому работать со своими репо. (А наловить в соседних джунглях нормальных разработчиков - уже тоже не шмагла, нету там.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #98, #135

91. Сообщение от Аноним (44), 26-Сен-26, 00:00	+/–
> что зеркалирование репозитория, так что в него нельзя будет коммитить. Можно, есть протокол file:// >не умеет обновляться из одной репы (например регулярно синхронизируемой локальной копии удалённого репозитория при нестабильном интернете), а коммитить в другую В клиенте лежит только одна ревизия. Что ты там собрался обновлять, не ясно. Но тебе никто не мешает подтянуть патчи из локальной репы и синхронизировать с удалённой. Вручную муторно, но автоматизация делается за пару вечеров. Только никому это не надо сейчас. Слишком уж редкий кейс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #100

93. Сообщение от пох.. (?), 26-Сен-26, 00:02	+/–
> Почему ты употребляешь слово "костыли"? Какое, по-твоему, некостыльное решение работы > с репозиторием в 1Тб на 10 миллиардов файлов, если тебе из > него нужно 1%, но ты наперёд не знаешь пути, которые нужны? Узнать у кого-то кто знает, какие нужны. И скачать только нужные. Для этого у нормального проекта есть нормальная структура и документация. (мало скачать, надо ж еще собрать потом суметь только отдельный кусок) Божку с пальцем оно разумеется не надо, у него до сих пор out-of-tree даже модуль собрать без кучи костылей не получается. Ему самому ведь и незачем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

94. Сообщение от Аноним (94), 26-Сен-26, 00:03	+1 +/–
За выкрутасы последних лет, начиная с выпиливания прокрутки консоли, точно не надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

95. Сообщение от Аноним (44), 26-Сен-26, 00:04	+1 +/–
>git это децентрализованная система хранения версий Пока есть центральный сервер. Иначе у тебя будет локальная копия со своей историей. Можешь поднять на свой сервак, но толку мало. >А с git достаточно git remote add && git push Тоже самое ты сделаешь с помощью svnadmin dump и поднимаешь на новом сервере. Никакой разницы от слова совсем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #123

96. Сообщение от пох.. (?), 26-Сен-26, 00:05	+/–
> Вместо этого они используют BitKeeper :) Это просто у одного финского в-то-время-нестудента > не хватило денег на лицензию, Ему ее нахаляву выдали (такое промо да упустить!). Но там был nih синдром помноженный на (закономерную) нелюбовь других разработчиков ставить себе неведомую хрень ради щастья порежьте-перепошлите. Причем бесплатность лицензии была обложена кучей условий, сделанных только под его величество.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #105, #136

97. Сообщение от пох.. (?), 26-Сен-26, 00:07	+/–
> Есть, работает не только поверх ssh. Достаточно запустить и в nginx сделать > proxy_pass. а теперь попробуй эту дрянь сделать не readonly и еще чтоб хоть как-то контролировать доступ. "достаточно поставить и настроить гитлаб", да? И ноль возможности дать доступ только к части репо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #137

98. Сообщение от Аноним (44), 26-Сен-26, 00:07	+/–
>что это костыль Который сделали для решения проблем с гитом. Второй костыль это модули. Тоже криво и косо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #102

99. Сообщение от Аноним (44), 26-Сен-26, 00:09	+1 +/–
> в svn работать комфортно невозможно Работает всё. Никакой разницы нет. Ну разве что в гит нет докачки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

100. Сообщение от пох.. (?), 26-Сен-26, 00:15	+1 +/–
> ясно. Но тебе никто не мешает подтянуть патчи из локальной репы > и синхронизировать с удалённой. Вручную муторно, но автоматизация делается за пару > вечеров. Только никому это не надо сейчас. Слишком уж редкий кейс. Сейчас это не надо только потому что везде с усердием д-ла впиндюрен гит. А раньше как-то так примерно и работали, если надо было значительный кусок сделать отдельно от основного проекта. Не работало там другое - очень неудобно было вести свой, параллельный проекту форк, не предназначенный для мержа в принципе (костыль существовал но был чудовищно неудобным). Вот это единственная проблема, которую действительно решают dvcs, но лучше б это был не git. Как обычно, рыночек порешал в пользу самого убогого и уе...щного решения затобесплатново.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #125

101. Сообщение от Аноним (44), 26-Сен-26, 00:18	+/–
>git-lfs Костыль. >Нет, не будет. Ты этой репликой просто расписался в непонимании базовых принципов работы git - он использует контентно-адресуемое хранилище В этом и проблема. Точнее много проблем, но ты почему-то уверен, что это лучшее решение и зачем-то обвиняешь меня в непонимании. >Модемщики-любители Вот, опять себя причисляешь к элитному клубу почитателей гита, пытаясь скрыть реальные проблемы. Но http умеет докачку. Просто подумай. >Сервак git просто отдаёт pack, это тупо готовый уже сжатый файл, в него даж смотреть не нужно. Его и скачивать не нужно в большинстве случаев. >svn да - там нагрузка Она в разы в меньше, так как качается только последняя ревизия. >Ой, это чушь, тем более что вы уже расписались. А без плача Ярославны ты в состоянии общаться? Или тебе реально больно, когда кто-то критикует твой святой гит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #114

102. Сообщение от пох.. (?), 26-Сен-26, 00:22	+/–
> Который сделали для решения проблем с гитом. Второй костыль это модули. Тоже > криво и косо. ну блин, других разработчиков (уже) нет. Раз уж даже ms (которая как минимум не зависела от мнений тусовочки) была вынуждена костылить чёдали, вместо того чтоб сделать свое нормально. и мордокнига со своим форком на нескучном йезычке туда же - за шесть лет шмагли во враппер, вызывающий гит с правильными флажками.  Могли бы уже команды чтоль выучить вместо этого. нам тут ловить точно нечего :-(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98

103. Сообщение от penetrator (?), 26-Сен-26, 01:01	+1 +/–
The "scalar" addition from Microsoft is now part of the core Git installation. 2.38.0 как раз для крупных монореп его предок был GVFS если я все правильно помню
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

104. Сообщение от пох.. (?), 26-Сен-26, 01:23	+1 +/–
мда. тут комментировать - только портить. Ты ведь во всех вещах такой же специалист, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #112

105. Сообщение от Аноним10084 и 1008465039 (?), 26-Сен-26, 01:24	+/–
Историю я перечитал перед тем, как постить, да. А ещё смешно, что отозвали у Линуса эту "бесплатную" лицензию потому, что Эндрю Триджелл отреверсил протокол биткипера, чтобы извлекать данные из него. Тот самый Триджелл, который недавно прославился нейрослопом и последовавшими за ним багами в rsync.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

106. Сообщение от Аноним (106), 26-Сен-26, 03:27	+/–
Ну и как, к примеру, просмотреть лог ветки, не клонируя её, не делая fetch, и не прибегая к внешним инструментам типа веб-интерфейсов?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #141

107. Сообщение от Аноним (19), 26-Сен-26, 03:29	+/–
Необходимость скачать даже 100МБ не нужной мне истории или кода - уже много.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #118

108. Сообщение от Сладкая булочка (?), 26-Сен-26, 03:34	+/–
>>> Лишите любой проект доступа к центральному сереверу на GitHub и к его аналогам и проект умрёт. >> Формально нет. Отвалятся баг репорты, пулл реквесты, CI, но код можно с > можно. Только это будет - мертвый код. > И проблема не в том что начнут какие-то хипстеры, а в том > что ты останешься с кодом, который некому сопровождать. А это совсем-совсем > не про кое-как суметь собрать в своем хомяке. Есть много проектов, которые закрывали на гитхабе и они переезжали в другое место.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #115

109. Сообщение от Сладкая булочка (?), 26-Сен-26, 03:38	+/–
>> Посыл один: большие монорепы git не выдерживает > Нет, посыл не такой. Посыл - большин монорепы не выдерживает ни git > ни svn. Я не защищаю svn. Просто спрашивали про git. Но svn подольше продержится для монорепы. >> поэтому у всех свои костыли. > Почему ты употребляешь слово "костыли"? Какое, по-твоему, некостыльное решение работы > с репозиторием в 1Тб на 10 миллиардов файлов, если тебе из > него нужно 1%, но ты наперёд не знаешь пути, которые нужны? Интересная задача) Узнать путь из дерева файлов веб морды?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

110. Сообщение от Аноним (110), 26-Сен-26, 03:55	+/–
> Новая папка (14) Имя твоё неизвестно. Подвиг твой бессмертен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #117

111. Сообщение от Аноним (111), 26-Сен-26, 08:52	+/–
> понадобился централизованный обзор изменений - сделали githab и аналоги Вот только их нет. Есть централизованный набор других артефактов разработки, а набор изменений уже на автопилоте децентрализовано используют. Так как без этого никуда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

112. Сообщение от Аноним (112), 26-Сен-26, 08:55	+/–
Да! Вы друг друга стоите. Можно сказать нашли друг друга. ....утые!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

113. Сообщение от ptr (ok), 26-Сен-26, 09:00	+/–
> Большинство бинарных форматов - сжатые данные, при изменении они жмутся сызнова > и общих частей вдоль истории примерно 0 целых 0 сотых. У Вас очень специфический опыт работы с бинарными данными. На практике - с точностью наоборот. При редактировании любительского видео изменяются только блоки от ключевого кадра до следующего. При редактировании професионального видео - вообще только отредактированные кадры. Многие проприетарные продукты в своих файлах имеют тупо страничную организацию, как в БД, из-за чего там после редактирования изменяются только страницы, затронутые модификациями. > Да, 500мб репу по модему не скачает, расходимся. Когда оптика падает и приходится работать через модем, то и гигабайтный репозиторий скачивает. Но далеко не всегда с первого раза.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

114. Сообщение от Аноним (114), 26-Сен-26, 09:04	+/–
> Вот, опять себя причисляешь к элитному клубу почитателей гита, пытаясь скрыть реальные проблемы. Но http умеет докачку. Просто подумай. Зачем это? У тебя проблемы? Используй: git clone --depth 1 <URL_репозитория> А затем: git fetch --depth 2 И так далее. Обычно и первой команды хватает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

115. Сообщение от zionist (ok), 26-Сен-26, 09:10	+/–
> Есть много проектов, которые закрывали на гитхабе и они переезжали в другое > место. На другой центральный сервет. То есть так или иначе без центрального сервера Git в команде бесполезен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #120, #124

116. Сообщение от zionist (ok), 26-Сен-26, 09:19	+1 +/–
> Нет, git это децентрализованная система хранения версий, а используется централизованно она потому что это удобно. Не потому что это удобно, а потому что распределённость Git попросту недоделана и доделывать её никто не собирается. Скорее всего в интересах корпораций, которые как раз таки заинтересованы в существовании центральных серверов с репозиториями. Просто для сравнения, есть такая пиринговая даркнет сеть Freenet для хранения и обмена файлами. Так вот во Freenet нет необходимости в каком либо центральном сервере. Распределённость Freenet настоящая, а распределённость Git мнимая и в реальной жизни никогда не работающая. Например нет механизма обмена remotes. На практике нет настоящих pull requests. В GitLab их даже честно переименовали в merge requests.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #121

117. Сообщение от user1985 (?), 26-Сен-26, 09:23	+/–
Самый популярный исполнитель всех времён и народов - "Unknown Artist".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

118. Сообщение от ыыы (?), 26-Сен-26, 10:02	+/–
Сегодня история не нужна, а завтра (при ловле бага) может оказаться срочно нужна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

119. Сообщение от Аноним (119), 26-Сен-26, 10:18	+/–
> В svn ты можешь счекаутить только нужную директорию с проектом последней ревизии, что будет скажем 100 Мб, а не весь чекаут в 30 Гб. Про полный git clone можно вообще умолчать. git clone --no-checkout --depth 1 <URL_РЕПОЗИТОРИЯ> git sparse-checkout init --cone git sparse-checkout set <ПУТЬ_К_НУЖНОЙ_ПАПКЕ> git checkout
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

120. Сообщение от Аноним (120), 26-Сен-26, 10:22	+/–
> На другой центральный сервет. То есть так или иначе без центрального сервера Git в команде бесполезен. На сколько ... надо быть? Ты спокойно делаешь клон и работаешь. Свой клон. Полностью рабочий и именно тебе на твой сервер могут комитить патчи друзья. А потом уже заливать в общественный. Ты, очевидно, вообще не относишься к разработке, раз не понимаешь элементарного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #128

121. Сообщение от Инопланетянин (?), 26-Сен-26, 14:47	+1 +/–
>> Нет, git это децентрализованная система хранения версий, а используется централизованно она потому что это удобно. > Не потому что это удобно, а потому что распределённость Git попросту недоделана > и доделывать её никто не собирается. Скорее всего в интересах корпораций, > которые как раз таки заинтересованы в существовании центральных серверов с репозиториями. > Просто для сравнения, есть такая пиринговая даркнет сеть Freenet для хранения > и обмена файлами. Так вот во Freenet нет необходимости в каком > либо центральном сервере. Распределённость Freenet настоящая, а распределённость Git > мнимая и в реальной жизни никогда не работающая. Например нет механизма > обмена remotes. На практике нет настоящих pull requests. В GitLab их > даже честно переименовали в merge requests. https://radicle.dev/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116 Ответы: #150

122. Сообщение от Аноним (-), 26-Сен-26, 15:39	+1 +/–
> Спустя более шести лет с прошлого > значительного выпуска Эй, посетители! Не трогайте экспонаты руками! Даже если они и выглядят как живые - они неплохо сохранились.
Ответить | Правка | Наверх | Cообщить модератору

123. Сообщение от Аноним (-), 26-Сен-26, 15:44	+/–
> Пока есть центральный сервер. Иначе у тебя будет локальная копия > со своей историей. Можешь поднять на свой сервак, но толку мало. Этот "центральный сервер"... 1) Любая копия гит может им выступить. Вопрос лишь в договоренностях. 2) Вообще не единственная возможная модель обмена патчами. Даже и сервера то может не быть, можно хоть флоппинетом патчи таскать. Git так то - похрен. 3) В случае нужды за 5 минут поднимается в другом месте. Потому что у каждого полная история изменений. > Тоже самое ты сделаешь с помощью svnadmin dump и поднимаешь на новом > сервере. Никакой разницы от слова совсем. Кроме того момента что если я не админ в том проекте - я вообще так не смогу. А с версиями svn с точки зрения разработки работает - никак. Чекаут энных версий тормозной что капец. А так по приколу мы вон там с господами bundle друг другу кидаем. Для вот именно распределенной модели разработки. Никаких серверов - нет совсем. Удачи так с svn вообще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

124. Сообщение от Аноним (-), 26-Сен-26, 15:46	+/–
> На другой центральный сервет. То есть так или иначе без центрального > сервера Git в команде бесполезен. Вообще ниоткуда не следует. Можно патчи хоть флоппинетом таскать - без каких либо серверов вообще. Вопрос регламентов и договоренностей. А SVN это какая-то кривая файлокачалка на стероидах которую по недоразумению назвали контролем версий. Хотя вот именно контроль версий она делает - отвратнейше. Тормозно и качая половину интернета на каждую версию. И вообще превращаясь без центрального сервера в тыкву.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #129

125. Сообщение от Аноним (-), 26-Сен-26, 15:48	+/–
> Как обычно, рыночек порешал в пользу самого убогого и уе...щного решения затобесплатново. Ты можешь платить за офигенные решения - и обмениваться патчами... сам с собой. Все равно твое гениальное величество врядли нуждается в "этом мусоре" от всяких атм "слизняков" и прочих "неумех". Вот и девелопай сам с собой!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

126. Сообщение от Аноним (-), 26-Сен-26, 15:49	+/–
> можно. Только это будет - мертвый код. Как видим ныть будут не только хипстеры - но и дубовые необучахи их совковых недокорп.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

127. Сообщение от Аноним (-), 26-Сен-26, 15:53	–1 +/–
> В общем, по итогу оказалось что и когда cvs использовали, и когда svn, > нам просто был нужен git - с ним все эти проблемы забылись как страшный сон. Все эти CVS и особенно SVN - кодили так как привыкли печальные винтики под корпами. А в git сначала подумали и применили - распределенную модель разработки Linux kernel. Которая так то пожалуй 1 из самых эффективных паттернов девелопа на планете, что бы там другие не вещали. Половина взялись косплеить именно те модели. Ну и гит им ессно мигом зашел.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #130

128. Сообщение от zionist (ok), 26-Сен-26, 17:16	+/–
>> На другой центральный сервет. То есть так или иначе без центрального сервера Git в команде бесполезен. > На сколько ... надо быть? Ты мне расскажи на сколько ты ... если написал весь этот бред. > Ты спокойно делаешь клон и работаешь. Свой клон. Полностью рабочий и именно > тебе на твой сервер могут комитить патчи друзья. А потом уже > заливать в общественный. Какой сервер? Я сижу за NAT через ширпотребный провайдер интернета с динамическим IP адресом. Ты мне предлагаешь дома сервер поднимать или снова к дяде на облаке идти? Тем временем даркнетовский Freenet прекрасно работает для всех. > Ты, очевидно, вообще не относишься к разработке, раз не понимаешь элементарного. Ты, очевидно, обычный подросток нуб, который нахватался по вершкам, да не понял по корешкам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120

129. Сообщение от zionist (ok), 26-Сен-26, 17:29	+/–
>> На другой центральный сервет. То есть так или иначе без центрального >> сервера Git в команде бесполезен. > Вообще ниоткуда не следует. Можно патчи хоть флоппинетом таскать - без каких > либо серверов вообще. Вопрос регламентов и договоренностей. Можно и TCP/IP голубями реализовать, даже RFC с описанием этого есть. Вот только на практике никто так делать не будет, равно как и пулл реквесты дискетами таскать. На практиве все используют исключительно и только централизованный GitHub или любой другой его аналог, который так же централизованный. Больше одного remote мало кто использует, а больше двух (один origin, другой - личный форк) вообще никто. Распределённость Git весьма иллюзорна. Торвальдс и компания до сих пор сидят на примитивных списках рассылки и вот так по-дедовски принимают и обсуждают патчи. Поддержку этого старческого workflow засунули даже в Git, что как бы намекает на его недоделанность и ущербность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #131, #139

130. Сообщение от BrainFucker (ok), 26-Сен-26, 19:05	+1 +/–
> А в git сначала подумали и применили - распределенную модель разработки Linux kernel. Там вроде делали по аналогии с использовавшимся ими до git проприетарным darks?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127 Ответы: #134

131. Сообщение от пох.. (?), 26-Сен-26, 20:07	+/–
> вот так по-дедовски принимают и обсуждают патчи. Поддержку этого старческого workflow > засунули даже в Git, что как бы намекает на его недоделанность В смысле, засунули? Весь гит и был построен вокруг этого тогда модного и молодежного цафедраль вс базар воркфвлова. Именно поэтому он такой уе..щный. Остальные в это время делали себе для ревью нормальные интерфейсы для работы с исходниками, не зависящие напрямую от vcs,  разумеется, в тогдашнем вебе, который уже был вполне для этого пригодным, а не выискивать в бороде емейлов стопиццотый ответ-на-ваш-ответ-ой-тут письмо не дошло. гит и тут был последним. но с деньгами ibm не посоревнуешься. даже ms и мордокнига посопротивлялись-посопротивлялись и жрутчодали. ms еще и возглавить ухитрилась.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #132, #133

132. Сообщение от zionist (ok), 26-Сен-26, 20:47	+/–
Причём тут вообще базар? В Git нет нормальной распределённости и это вообще не про то, как организовано обсуждение кода. Операция pull в словосочетании pull request - это пара двух более базовых операций - fetch и merge или fetch и rebase. В любом случае принимающей настоящий pull request стороне необходимо получить request и сделать fetch. Первое Git не поддерживает вообще никак. Второе поддерживает через добавление дополнительного remote вручную и у другой стороны обязательно должен быть свой доступный снаружи Git сервер. При этом Git не поддерживает ни аутентификацию, ни права доступа и вообще ничего, что такому серверу крайне необходимо. Именно поэтому Торвальдс может легко перейти на SVN, без какого-то ущерба распределённости. PR-ы продолжат приходить мылом и в случае принятия продолжат комититься на центральный сервер на git.kernel.org ну то есть уже на svn.kernel.org Принципиально не поменяется ровным счётом ничего. Фактически именно Pull Request не делает никто, включая финско-шведского автора Git-а.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #143

133. Сообщение от zionist (ok), 26-Сен-26, 20:48	+/–
Причём тут вообще базар? В Git нет нормальной распределённости и это вообще не про то, как организовано обсуждение кода. Операция pull в словосочетании pull request - это пара двух более базовых операций - fetch и merge или fetch и rebase. В любом случае принимающей настоящий pull request стороне необходимо получить request и сделать fetch. Первое Git не поддерживает вообще никак. Второе поддерживает через добавление дополнительного remote вручную и у другой стороны обязательно должен быть свой доступный снаружи Git сервер. При этом Git не поддерживает ни аутентификацию, ни права доступа и вообще ничего, что такому серверу крайне необходимо. Именно поэтому Торвальдс может легко перейти на SVN, без какого-то ущерба распределённости. PR-ы продолжат приходить мылом и в случае принятия продолжат комититься на центральный сервер на git.kernel.org ну то есть уже на svn.kernel.org Принципиально не поменяется ровным счётом ничего. Фактически именно Pull Request не делает никто, включая финско-шведского автора Git-а.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #140

134. Сообщение от Аноним (-), 26-Сен-26, 21:24	–1 +/–
>> А в git сначала подумали и применили - распределенную модель разработки Linux kernel. > Там вроде делали по аналогии с использовавшимся ими до git проприетарным darks? Может, таки, BitBaker уж, когда тот залупился и лицензию отозвал? Ну да, способный архитект - дерет идеи отовсюду где видит что-то дельное :). Главное то - удачный набор свойств под задачу получить. И роялит все же комбинация свойств а не сферический EPIC WIN по 1 параметру в вакууме.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130

135. Сообщение от Аноним (-), 26-Сен-26, 21:31	+/–
> но (microsoft!) когда-то нешмагла по другому работать со своими репо. (А наловить > в соседних джунглях нормальных разработчиков - уже тоже не шмагла, нету > там.) Потому что сами они вообще - TFS и прочие Source Safe и как их там только рожать умели. Совершенно хтонические штуки где вы не можете редактировать файло если его коллега зачекаутил. Кого-то еще удивляет что MS скупил гитхаб а эти ужастики дает только особо отбитым клиентам желающим странного? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

136. Сообщение от Аноним (-), 26-Сен-26, 21:34	+/–
> Ему ее нахаляву выдали (такое промо да упустить!). Но там был nih > синдром помноженный на (закономерную) нелюбовь других разработчиков ставить себе неведомую > хрень ради щастья порежьте-перепошлите. Но сильнее всего синдром подогрел - как обычно - залуп проприетария отозвавшего лиензию. С аргументом что какие-то фрики видите ли смеют протокол реверсить и свои фронты к нему писать. Как еще популярнее отрекламить парадигмы опенсорс толпе програмеров я даже и не знаю :). А Торвальдс еще и малость не тот кто ведется на гопстоп, он может и сам шашкой помахать если стало ну очень надо. И как видим - замахал как обычно всех. И этого биткипера заодно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

137. Сообщение от Аноним (-), 26-Сен-26, 21:35	+/–
> а теперь попробуй эту дрянь сделать не readonly и еще чтоб хоть > как-то контролировать доступ. > "достаточно поставить и настроить гитлаб", да? Ну попробуй поставить что-то сравнимое с гитлабом для этого твоего SVN вообще. Заодно и поговорим что там проще :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #142

138. Сообщение от Аноним (-), 26-Сен-26, 21:37	+/–
> Расшифруй аббревиатуру SCV. Дай угадаю, Sistema Controlya Versiy? SCV это такой сервисный юнит в Старкрафте, ковыряет минералы и строит здания. Ну и первым собирает все п..ли :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

139. Сообщение от Аноним (-), 26-Сен-26, 21:44	+/–
> Можно и TCP/IP голубями реализовать, даже RFC с описанием этого есть. Вот > только на практике никто так делать не будет, Вообще-то кто-то прикололся - и даже заимплементил. И даже выхлоп команды ping запостил. Латенси конечно великоват и 1 пакет вообще потерялся, но все же :) > равно как и пулл реквесты дискетами таскать. Дискетами - не таскаем, но bundle через tox какой - определенные выводки фриков так прикалываются :). А кто там что координирует - попробуй, разберись. > На практиве все используют исключительно и только > централизованный GitHub или любой другой его аналог, Я вообще мои кренделя на гитхаб забыл. А при попытке ресетнуть за...ся пытаться забороть супер-капчу от мс. Посчитаем что я бот и мне доступ к гитхабу не надо давать, так проще :) > который так же централизованный. Не совсем. У меня полная история со всеми прибабахами. И завтра мы можем допустим договориться и юзать точкой обмена мой сервак. Или даже присылать мне git bundles относительно вон того дерева. И вот уже я новый центр вселенной. Ну или Вася, если он ALL больше зашел. В принципе не важно кто - важно чтоб у нас дерево устаканилось одинаково. > Больше одного remote мало кто использует, а больше двух (один origin, > другой - личный форк) вообще никто. Распределённость Git весьма иллюзорна. Торвальдс > и компания до сих пор сидят на примитивных списках рассылки А я иногда с толпой кексов перекидываю git bundles через tox :). Довольно распределенная развлекуха. Нишевая? Может быть. А то что толпе нубоджунов хочется гитхаб - пусть и гадят там своими ценными проектами а майки это оплачивают, типа :). Не вижу минусов. > засунули даже в Git, что как бы намекает на его недоделанность > и ущербность. Проблема в том что все остальные на этом глобусе - даже так не смогли. А все groupware для девелопа это нашлепки над git и потуги реплея того процесса энтерпрайзными винтиками, с адаптацией для самых маленьких.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #154

140. Сообщение от Аноним (-), 26-Сен-26, 21:50	–2 +/–
> Причём тут вообще базар? В Git нет нормальной распределённости В git она на самом базовом уровне - есть деревья git. Мы так или иначе перекидываемся между ними и синхрим состояния. Как именно это произойдет и какие conventions в этом прцоессе - в структуры данных и алго гит вообще не входит и двуногие сами решат как им лучше. А так даже из распределенного торента можно псевдосерв сделать с каким-нибудь супер-сидером с более 9000 раздач. Это однако не отменяет того факта что он p2p.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #153

141. Сообщение от Аноним10084 и 1008465039 (?), 26-Сен-26, 23:26	–1 +/–
Нет, ну если в таких условиях, то мб. В svn кажется веб-интерфейс встроен
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

142. Сообщение от пох.. (?), 26-Сен-26, 23:30	+/–
для того чтобы сделать доступ к репо не ридонли и с раздельными правами для разных учеток - внезапно, не нужно херовертить ничего сравнимого с гитлабом, вот так сюрприз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #144

143. Сообщение от пох.. (?), 26-Сен-26, 23:45	+/–
> Именно поэтому > Торвальдс может легко перейти на SVN, без какого-то ущерба распределённости. PR-ы это не совсем так - есть особо одаренные сподвижники, осененные правом пулреквестов (и да, гитовый пулреквест - это вот именно "pull from me" в рассылочку). Если ты посмотришь вот сюда, https://git.kernel.org/pub/scm/linux/kernel/git/ - то вероятно сможешь приобщиться (я там увижу разумеется только анимешницу cpaную, ворующую чужие ресурсы) - и оценить что сборище костылестроителей не то чтоб миллионное, но и не пять рыл. Во времена svn приходилось давать этим ребятам право комитов прямо в основное дерево. (ну разумеется, кто комитил непроверенную хрень - того права быстренько бы лишили, пулреквесты и местечко под солнышком kernel/git тоже ни разу не наследственное дворянство) и ревью - if any - _после_ комита, когда твоя глупость уже всем станет видна (а манипуляции с историей хехе svn не поддерживает) Это вот пришлось бы поменять, и это достаточно на самом деле серьезный повод использовать dvcs. Но ты прав в том что гит сам по себе, без обертки в виде гитхаба, и тут феерически убог, и либо вот ты настолько велик и могуч что тебе доверяют секретный пароль от kernel.org, и позволяют ненадолго там обосноваться, и твой код уже вообще никто не читает, либо иди каквсе помельче и перепошлите в рассылку. Какое при этом может быть ревью не видя проекта в целом и после пятнадцатой итерации переправления colour на color - ну вон по десяткам cve в день можно оценить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #152

144. Сообщение от Аноним (-), 27-Сен-26, 00:27	+/–
> для того чтобы сделать доступ к репо не ридонли и с раздельными > правами для разных учеток - внезапно, не нужно херовертить ничего сравнимого > с гитлабом, вот так сюрприз. Гитлаб - это мягко говоря не про то. Это такое специализированное Groupware под девелоп софта. Вокруг гита, да. И он такой не один, для тех кому чуть поменьше - gogs и деривативы всякие есть типа Forgejo и что там еще. А вокруг SVN подобного софта - вообще толком нет с тем же фичесетом. Вот хоть как. А то что не нужно - соглашусь, с уточнением "как и весь SVN в данный момент". Актуальность svn в данный момент - нулевая. У меня он просто не установлен на девелоперских воркстейшне, ноуте, aux компе и проч. И я уже забыл когда мне надо было проект в svn. В крайнем случае  у таких проектов 100% бывают зеркала залитые на гитхабы, гитлабы и прочие codeberg. Потому что иметь дело с svn в 2026 году лишь чуть более ноля осталось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #147

145. Сообщение от Александр (??), 27-Сен-26, 06:40	+/–
Частичный чекаут. В гит вроде тоже есть, но только из консоли. Вообще, в gui и IDE плагинах git кучу функций не завозят, а жаль
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #151

146. Сообщение от Аноним (146), 27-Сен-26, 08:16	+/–
Ничего не слышно про hg. Обидно, он был самым адекватным. Питон и раст убьют любре хорошее начинание.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #148

147. Сообщение от пох.. (?), 27-Сен-26, 10:11	+/–
> Гитлаб - это мягко говоря не про то. а других вариантов просто предоставить доступ к репо тем другим васянам - даже в полностью изолированном от третьих васянов контуре и без всяких требований к безопастносте - у тебя с гитом не то чтобы и есть. Оно без костылей само стоять не может. Про бесконечные полуработающие клоны gogs, каждый день новые, рассказывай больным фрикам. А все потому что у божка с пальцем вон вообще никакого доступа васянов к его репо нет, он и счастлив. > У меня держи в курсе, что там у тебя под кроватью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144

148. Сообщение от пох.. (?), 27-Сен-26, 10:36	+/–
> Ничего не слышно про hg. Обидно, он был самым адекватным. тоже нет. там те же самые болячки что у гита, если ты хочешь хотя бы не ридонли доступ тем, другим васянам. Еще и даже для ридонли - этажерка корявых и дырявых питоноврапперов (уже ломали), потому что нескучный йезычок даже тут пошел своим неторенным путем через лес костылей (uwsgi и вот ето вот всьо). А без этого нафиг вообще нужна dvcs? И да, удивительно что афтыри этого не понимали. Да, механизм работы с кодом чуть ближе к svn и чуть проще и понятнее разработчику. Но это если разработчик вникает с нуля, а не вызубрил git push git rebase. Таким наоборот, никогда не разобраться, а этих обезьянок сейчас - большинство, и если ты хочешь с ними как-то сотрудничать, а не все токены оплачивать сам - придется сделать им экспорт в гит и вывалить на гитхап. (а иначе опять же - нафиг надо-то, когда есть svn и cvs) > Питон и раст убьют любре хорошее начинание. ну а это да, вишенка на тортике, вероятно hg где-то на периферии был бы еще сегодня жив, если бы автор не выбрал язычок быстрого тяпляпирования который через день несовместим сам с собой. Вся мощь Опуса оказалась неспособна с первой пары попыток починить скриптец на 3000 строк (и нет гарантий что не осталось ошибок даже сейчас, с тестами и плясками вокруг) - могу представить сколько теперь незаметных проблем в громадном коде hg (причем ломается при таком переписывании и python2, т.е. ее новую - вообще использовать нельзя если твои репо имеют для тебя хоть какую-то ценность) при этом кому-то оно все еще нужно - rhel8 все еще тащит за собой python2 ради hg (да, да - именно ради версии 4, еще неполоманной, и патчи в нее бэкпортит).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

149. Сообщение от Аноним (149), 27-Сен-26, 12:21    Скрыто ботом-модератором	+/–
Портфель из Windows ещё лучше. Интересная концепция, кстати.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

150. Сообщение от Ык (?), 27-Сен-26, 12:53	+/–
Это да, но что то я не вижу там интересных проектов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

151. Сообщение от Аноним10084 и 1008465039 (?), 27-Сен-26, 17:04	+/–
Не знаю как с этим обстоит дело у svn, но никогда в git не пользовался GUI. Как-то оно неудобно, легче уж в командной строке указать, что конкретно хочешь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145

152. Сообщение от zionist (ok), 27-Сен-26, 17:53	+/–
>> Именно поэтому >> Торвальдс может легко перейти на SVN, без какого-то ущерба распределённости. PR-ы > > это не совсем так - есть особо одаренные сподвижники, осененные правом пулреквестов > (и да, гитовый пулреквест - это вот именно "pull from me" > в рассылочку). Если ты посмотришь вот сюда, https://git.kernel.org/pub/scm/linux/kernel/git/ > - то вероятно сможешь приобщиться (я там увижу разумеется только анимешницу > cpaную, ворующую чужие ресурсы) - и оценить что сборище костылестроителей не > то чтоб миллионное, но и не пять рыл. Несколько Git репозиториев, физически находящихся на одном сервере git.kernel.org - это тот же PornGitHub, вид сбоку. Где же тут распределённость? Я даже имею опыт личного контрибьютинга в ядро. Однажды послал им минорное исправление - просто было интересно пройти этот квест. Я его таки прошёл и мои изменения уже какое-то время находятся в релизах, но впечатления остались довольно негативные. Пришлось настравивать секцию [sendemail] в моём ~/.gitconfig а до этого ещё и мудохаться с Gmail и выяснением как сгенерировать этот чёртов smtpPass. Ну и как ты понимаешь, держать smtpPass в ~/.gitconfig - это вообще несекьюрно. Просто прислать им патч как plain text мылом так же нельзя, потому что Gmail его врапит, а в виде аттачмента не поддерживается уже на стороне git.kernel.org Ну а участие в обсуждении присланного патча, через архив спика рассылки и всё ту же функциональность Git для отсылки почты подходит лишь для сильных духом. А теперь скажи мне сам, только честно, это похоже на распределённую разработку в 2026 году или это всё фуфло и профанация? > Во времена svn приходилось давать этим ребятам право комитов прямо в основное > дерево. (ну разумеется, кто комитил непроверенную хрень - того права быстренько > бы лишили, пулреквесты и местечко под солнышком kernel/git тоже ни разу > не наследственное дворянство) и ревью - if any - _после_ комита, > когда твоя глупость уже всем станет видна (а манипуляции с историей > хехе svn не поддерживает) С тех пор ничего принципиально не изменилось. Мержить могут лишь люди с правами. Когда ты делаешь git fetch новые объекты из чужой репы попадают в твою общую репу. Разграничение на local/remote там чисто логическое, потому что key-value хранилище общее. > Это вот пришлось бы поменять, и это достаточно на самом деле серьезный > повод использовать dvcs. Нормального dvcs как не было так и нет. > Но ты прав в том что гит сам по себе, без обертки > в виде гитхаба, и тут феерически убог, и либо вот ты > настолько велик и могуч что тебе доверяют секретный пароль от kernel.org, > и позволяют ненадолго там обосноваться, и твой код уже вообще никто > не читает, либо иди каквсе помельче и перепошлите в рассылку. Какое > при этом может быть ревью не видя проекта в целом и > после пятнадцатой итерации переправления colour на color - ну вон по > десяткам cve в день можно оценить. А ты задумайся, почему нужна та или иная обёртка? Не потому ли, что корпорации сильно попросили Торвальдса и того японца не развивать распределённость Git дальше? Секретный пароль от kernel.org не нужен. Достаточно просто иметь там персональный отдельный аккаунт для своих реп, примерно так же как в GitHub. Там такое уже есть, для избранных. Но это всё равно будет централизованным решением. А учитывая то, что ядро и GNU деды до сих пор предпочитают глиняные таблички, списки рассылки и прочие анахронизмы, они даже в функциональности GitHub смысла не видят. К code review это вообще не имеет никакого отношения. Из собственной практики я давно сделал вывод, что качественный code review проглядыванием одних лишь изменений попросту невозможен, иначе это банальная профанация. Особенно в корпоративной среде, где на code review просто не выделяют время и народ апрувит после чтения по диагонали и побыстрей, дабы коллега в будущем так же не задерживал слишком каверзными придикрами. Для нормального code review необходима среда разваботки с навигацией по коду всего проекта. Поэтому разглядывать изменения что в вебморде GitHub, что в почтовом клиенте - это одинаково непрофессионально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143

153. Сообщение от zionist (ok), 27-Сен-26, 18:01	+/–
Поддержка операций fetch и push, вмести с поддержкой нескольких вручную настраиваемых remote репозиториев ещё не делает Git распределённым. Всё это лишь зачатки распределённости уровня PoC, но никак не законченное решение и даже не MPV.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

154. Сообщение от zionist (ok), 27-Сен-26, 18:24	+/–
>> Можно и TCP/IP голубями реализовать, даже RFC с описанием этого есть. Вот >> только на практике никто так делать не будет, > > Вообще-то кто-то прикололся - и даже заимплементил. И даже выхлоп команды ping > запостил. Латенси конечно великоват и 1 пакет вообще потерялся, но все > же :) Но всё же это годится лишь для лулзов. >> равно как и пулл реквесты дискетами таскать. > > Дискетами - не таскаем, но bundle через tox какой - определенные выводки > фриков так прикалываются :). А кто там что координирует - попробуй, > разберись. Какое это имеет отношение к Git? >> На практиве все используют исключительно и только >> централизованный GitHub или любой другой его аналог, > > Я вообще мои кренделя на гитхаб забыл. А при попытке ресетнуть за...ся > пытаться забороть супер-капчу от мс. Посчитаем что я бот и мне > доступ к гитхабу не надо давать, так проще :) Попробуй связаться с их суппортом. Мне они как-то помогли восстановить доступ к старому аккаунту, который был завязан на старую же почту, которую Gmail закрыл за неиспользование. >> который так же централизованный. > > Не совсем. У меня полная история со всеми прибабахами. И завтра мы > можем допустим договориться и юзать точкой обмена мой сервак. Или даже > присылать мне git bundles относительно вон того дерева. И вот уже > я новый центр вселенной. Ну или Вася, если он ALL больше > зашел. В принципе не важно кто - важно чтоб у нас > дерево устаканилось одинаково. Послезавтра у тебя диск ляжет и вся твоя история отправится на небеса, где рукописи не горят. И даже если ты решишь развернуть сервак, бэкап и всё как положено, это всё будет размещаться на серверах дяди буржуина, воак активиста или носителя других тараканов в голове. Вон недавно codeberg запретили любые репы с любым навайбкоженым кодом, любым даже ненавайбкоженым кодом для вайбкодинга и для крипты. А у меня там как раз навайбкоженая репа сидит, исключительно потому, что она SHA-256, а GitHub такое не поддерживает и ещё не скоро начнёт. В любой момент эти немецкие левопередасты могут мне репу снести, потому что могут. Ну и где тут распределённость? >> Больше одного remote мало кто использует, а больше двух (один origin, >> другой - личный форк) вообще никто. Распределённость Git весьма иллюзорна. Торвальдс >> и компания до сих пор сидят на примитивных списках рассылки > > А я иногда с толпой кексов перекидываю git bundles через tox :). Ну ты знатный извращенец. Ты бы ещё перфокартами это делал. > Довольно распределенная развлекуха. Нишевая? Может быть. А то что толпе нубоджунов > хочется гитхаб - пусть и гадят там своими ценными проектами а > майки это оплачивают, типа :). Не вижу минусов. У нубоджунов просто нет альтернатив, как и у всех прочих. Ну а маргинальные извращения, вроде тобой тут упомянутого, на то и маргинальные чтобы не быть хоть сколько нибудь популярными. >> засунули даже в Git, что как бы намекает на его недоделанность >> и ущербность. > > Проблема в том что все остальные на этом глобусе - даже так > не смогли. А все groupware для девелопа это нашлепки над git > и потуги реплея того процесса энтерпрайзными винтиками, с адаптацией для самых > маленьких. Даркнет смогли, а человеческий DVCS не смогли? Не верь в сказки. Git поднялся исключительно на хайпе вокруг имени Линус Торвальдс. Без него даже про BitKeeper так никто бы и не узнал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема