Профиль: Аноним (вход | регистрация) неRU opennet.me  
OpenNET

[ новости /+++ | форум | теги |    ]



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

"Доступна система управления версиями Apache Subversion 1.15.0"  +/–
Сообщение от opennews (??), 25-Сен-26, 14:01 
Спустя более шести лет с прошлого значительного выпуска организация Apache Software Foundation опубликовала релиз централизованной системы управления версиями Subversion 1.15.0...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=66342

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

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

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

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

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

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

6. Сообщение от Аноним (6), 25-Сен-26, 14:42   +1 +/–
> на бумаге

пропустили - туалетной

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

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

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

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   –3 +/–
> Её ещё использую (да и централизованные 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   +/–
Выглядит как вброс, но на деле 20 лет назад когда CVS меняли на SVN, потеряли возможность быстро синкаться с локального зеркала репозитория. Интернет был плохой, и не иметь возможности закоммитить или лог посмотреть когда нужно - это был прям зашквар, и если cvs можно было просто указать другой сервер, svn такого не полволял, а переключение между апстримами там сделано через такую задницу что и вспоминать не хочется (но никогда не забуду что там есть команды `switch`, `rebase` и `switch --rebase`, и поди ты разберись какая для этого). В общем, по итогу оказалось что и когда cvs использовали, и когда svn, нам просто был нужен git - с ним все эти проблемы забылись как страшный сон.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

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   –1 +/–
классические - централизованные, git распределенный, потом когда git стали использовать как VCS понадобился централизованный обзор изменений - сделали githab и аналоги.
нет смысла спорить с реальностью, не делайте так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #30

21. Сообщение от Аноним10084 и 1008465039 (?), 25-Сен-26, 15:37   +4 +/–
Вот только смысл в строго централизованной VCS, если git абсолютно так же можно использовать квазицентрализованно? Зато если вдруг понадобиться децентрализация, она сразу будет из коробки.

Просто реально интересно узнать, какие, пусть специфические, фичи может даже svn по сравнению с git?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #106

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

23. Сообщение от Пыщь (?), 25-Сен-26, 15:50   +2 +/–
"Больше всего я жалею не о деньгах, а о том, что 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   +/–
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   +3 +/–
RCS лусше CVS. А Новая папка (14) лучше их всех вместе взятых.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #110

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   +/–
> В чём именно это выражается? Помню миграцию 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   +1 +/–
> git это система обмена изменениями, почитайте на досуге какую проблему решал Линус когда
> писал его.

Он никакую проблему не решал. Его как раз устраивала "новая папка 1.2.32"
Проблемы были не у Линуса, а у тех, других васянов - которым предлагалось порезать помельче и перепослать в рассылку, а они-то тогда пользовались cvs/svn, чтобы понимать кто из них чего наменял и где.

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

И его поделка автоматизирует именно этот, никому на свете кроме него ненужный workflow.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #73

53. Сообщение от Аноним (44), 25-Сен-26, 18:43   +1 +/–
>это решается отдельными инструментами, равно как и с 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   +1 +/–
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

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

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   +/–
Вот только трындеть не надо, свн прекрасно работает без серверов, репа создаётся в указанном месте на локальной ФС, после чего "клиент" 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   –1 +/–
> Потому что других способов работы с кодом - Линус не знал и знать не хотел.  
> И его поделка автоматизирует именно этот, никому на свете кроме него ненужный 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   +/–
> Время ох**тельных историй. Расскажи-ка, павлин, какие тогда были 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 +/–
Ответить | Правка | Наверх | 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   +1 +/–
> Ну да, конечно. Поднимать сервер с "удобной" SCV конечно "проще", и наверное не требует специальных навыков и денег на хостинг (нет), чем создать репозиторий на GitHub или подобном сервисе по нажатию кнопки

Расшифруй аббревиатуру SCV. Дай угадаю, Sistema Controlya Versiy?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

85. Сообщение от пох.. (?), 25-Сен-26, 23:44   –1 +/–
>> Лишите любой проект доступа к центральному сереверу на GitHub и к его аналогам и проект умрёт.
> Формально нет. Отвалятся баг репорты, пулл реквесты, CI, но код можно с

можно. Только это будет - мертвый код.

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

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

кстати, наличие у cvs интересного ключика -o как бы намекает, как во времена, когда диски были большими а влезало туда мало, относились к истории.

Считать ее самоценной - это вот как раз в svn зачем-то додумались.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #108

86. Сообщение от Аноним (14), 25-Сен-26, 23:48   +/–
> Git - это так же централизованная система хранения версий. По крайней мере только централизованно Git и используется.

Нет, git это децентрализованная система хранения версий, а используется централизованно она потому что это удобно. Разумеется, только когда это удобно - в других случаях она используется децентрализовано.

> Лишите любой проект доступа к центральному сереверу на GitHub и к его аналогам и проект умрёт.

Нет, так будет с svn. А с git достаточно git remote add && git push - и проект на новом центральном сервере. Или расшарить доступ - и проект на своём сервере. Или подтянуть radicle - и проект полностью децентрализован. Но всё ещё в git.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #95

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

91. Сообщение от Аноним (44), 26-Сен-26, 00:00   +/–
> что зеркалирование репозитория, так что в него нельзя будет коммитить.

Можно, есть протокол file://
>не умеет обновляться из одной репы (например регулярно синхронизируемой локальной копии удалённого репозитория при нестабильном интернете), а коммитить в другую

В клиенте лежит только одна ревизия. Что ты там собрался обновлять, не ясно. Но тебе никто не мешает подтянуть патчи из локальной репы и синхронизировать с удалённой. Вручную муторно, но автоматизация делается за пару вечеров. Только никому это не надо сейчас. Слишком уж редкий кейс.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #100

92. Сообщение от Аноним (92), 26-Сен-26, 00:01   +/–
Это растопрограммисты?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

93. Сообщение от пох.. (?), 26-Сен-26, 00:02   +/–
> Почему ты употребляешь слово "костыли"? Какое, по-твоему, некостыльное решение работы
> с репозиторием в 1Тб на 10 миллиардов файлов, если тебе из
> него нужно 1%, но ты наперёд не знаешь пути, которые нужны?

Узнать у кого-то кто знает, какие нужны. И скачать только нужные. Для этого у нормального проекта есть нормальная структура и документация.
(мало скачать, надо ж еще собрать потом суметь только отдельный кусок)

Божку с пальцем оно разумеется не надо, у него до сих пор out-of-tree даже модуль собрать без кучи костылей не получается. Ему самому ведь и незачем.



Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

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

95. Сообщение от Аноним (44), 26-Сен-26, 00:04   +1 +/–
>git это децентрализованная система хранения версий

Пока есть центральный сервер. Иначе у тебя будет локальная копия со своей историей. Можешь поднять на свой сервак, но толку мало.

>А с git достаточно git remote add && git push

Тоже самое ты сделаешь с помощью svnadmin dump и поднимаешь на новом сервере. Никакой разницы от слова совсем.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

96. Сообщение от пох.. (?), 26-Сен-26, 00:05   +/–
> Вместо этого они используют BitKeeper :) Это просто у одного финского в-то-время-нестудента
> не хватило денег на лицензию,

Ему ее нахаляву выдали (такое промо да упустить!). Но там был nih синдром помноженный на (закономерную) нелюбовь других разработчиков ставить себе неведомую хрень ради щастья порежьте-перепошлите.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #105

97. Сообщение от пох.. (?), 26-Сен-26, 00:07   +/–
> Есть, работает не только поверх ssh. Достаточно запустить и в nginx сделать
> proxy_pass.

а теперь попробуй эту дрянь сделать не readonly и еще чтоб хоть как-то контролировать доступ.

"достаточно поставить и настроить гитлаб", да?

И ноль возможности дать доступ только к части репо.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

98. Сообщение от Аноним (44), 26-Сен-26, 00:07   +/–
>что это костыль

Который сделали для решения проблем с гитом. Второй костыль это модули. Тоже криво и косо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #102

99. Сообщение от Аноним (44), 26-Сен-26, 00:09   +1 +/–
> в svn работать комфортно невозможно

Работает всё. Никакой разницы нет. Ну разве что в гит нет докачки.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

100. Сообщение от пох.. (?), 26-Сен-26, 00:15   +/–
> ясно. Но тебе никто не мешает подтянуть патчи из локальной репы
> и синхронизировать с удалённой. Вручную муторно, но автоматизация делается за пару
> вечеров. Только никому это не надо сейчас. Слишком уж редкий кейс.

Сейчас это не надо только потому что везде с усердием д-ла впиндюрен гит.

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

101. Сообщение от Аноним (44), 26-Сен-26, 00:18   +/–
>git-lfs

Костыль.

>Нет, не будет. Ты этой репликой просто расписался в непонимании базовых принципов работы git - он использует контентно-адресуемое хранилище

В этом и проблема. Точнее много проблем, но ты почему-то уверен, что это лучшее решение и зачем-то обвиняешь меня в непонимании.

>Модемщики-любители

Вот, опять себя причисляешь к элитному клубу почитателей гита, пытаясь скрыть реальные проблемы. Но http умеет докачку. Просто подумай.

>Сервак git просто отдаёт pack, это тупо готовый уже сжатый файл, в него даж смотреть не нужно.

Его и скачивать не нужно в большинстве случаев.

>svn да - там нагрузка

Она в разы в меньше, так как качается только последняя ревизия.

>Ой, это чушь, тем более что вы уже расписались.

А без плача Ярославны ты в состоянии общаться? Или тебе реально больно, когда кто-то критикует твой святой гит?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

102. Сообщение от пох.. (?), 26-Сен-26, 00:22   +/–
> Который сделали для решения проблем с гитом. Второй костыль это модули. Тоже
> криво и косо.

ну блин, других разработчиков (уже) нет. Раз уж даже ms (которая как минимум не зависела от мнений тусовочки) была вынуждена костылить чёдали, вместо того чтоб сделать свое нормально.

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

нам тут ловить точно нечего :-(

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98

103. Сообщение от penetrator (?), 26-Сен-26, 01:01   +/–
The "scalar" addition from Microsoft is now part of the core Git installation.

2.38.0

как раз для крупных монореп

его предок был GVFS если я все правильно помню

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

104. Сообщение от пох.. (?), 26-Сен-26, 01:23   +/–
мда. тут комментировать - только портить.

Ты ведь во всех вещах такой же специалист, да?


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

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

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

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

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

Есть много проектов, которые закрывали на гитхабе и они переезжали в другое место.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

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


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

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




XSQUARE
Inferno Solutions
Hosting by Hoster.ru
Хоcтинг:

Закладки на сайте
Проследить за страницей
Created 1996-2026 by Maxim Chirkov
Добавить новость, Поддержать