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

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

Доступна система управления версиями Apache Subversion 1.15.0

25.09.2026 13:55 (MSK)

Спустя более шести лет с прошлого значительного выпуска организация Apache Software Foundation опубликовала релиз централизованной системы управления версиями Subversion 1.15.0.

Ключевые улучшения Subversion 1.15:

  • Добавлен режим работы без кэширования базовых ревизий всех файлов на локальной системе (Pristines On Demand), позволяющий сократить размер рабочей копии на диске до 50% за счёт загрузки файлов с сервера по мере необходимости. Ценой снижения потребления дискового пространства является повышение сетевого трафика и увеличение времени при выполнении таких операций, как diff и revert. Отключение кэширования может оказаться полезным при работе с большими репозиториями с редко меняющимися файлами, при размещении рабочей копии на одном хосте с репозиторием, а также на системах с ограниченным дисковом пространством и быстрым сетевым подключением.
  • Реализован новый формат хранения рабочих копий (Format 32), адаптированный для работы без локального кэширования. Предоставлена возможность одновременного использования разных версий форматов рабочих копий, что позволяет сохранить формат ранее созданных рабочих копий без обновления существующих проектов командой "svn upgrade".
  • Добавлена поддержка потокового выполнения операций "svn checkout" и "svn update", значительно повышающего производительность и надёжность. Вместо копирования в промежуточный временный каталог c его последующим разбором, данные теперь сразу записываются в служебный и рабочий каталоги (вместо копирования из промежуточного каталога, файл по месту сохраняется под временным именем, а затем атомарно переименовывается).
  • Реализована новая система сборки на базе инструментария CMake, существенно упрощающая сборку на платформе Windows и интегрируемая с пакетным менеджером vcpkg для автоматической загрузки зависимостей. По умолчанию для всех платформ кроме Windows продолжает использоваться старая система сборки на базе Autoconf.


  1. Главная ссылка к новости (https://github.com/apache/subv...)
  2. OpenNews: Выпуск системы управления версиями Apache Subversion 1.14.0
  3. OpenNews: GitHub прекращает поддержку Subversion
  4. OpenNews: Выпущена система управления версиями Bazaar 2.7.0
  5. OpenNews: Canonical прекратит поддержку Bazaar в платформе Launchpad
  6. OpenNews: Выпуск распределённой системы управления версиями Mercurial 4.9
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/66342-subversion
Ключевые слова: subversion
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (104) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 14:01, 25/09/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/–
    CVS лучше.
     
     
  • 2.14, Аноним (14), 15:15, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Выглядит как вброс, но на деле 20 лет назад когда CVS меняли на SVN, потеряли возможность быстро синкаться с локального зеркала репозитория. Интернет был плохой, и не иметь возможности закоммитить или лог посмотреть когда нужно - это был прям зашквар, и если cvs можно было просто указать другой сервер, svn такого не полволял, а переключение между апстримами там сделано через такую задницу что и вспоминать не хочется (но никогда не забуду что там есть команды 'switch', 'rebase' и 'switch --rebase', и поди ты разберись какая для этого). В общем, по итогу оказалось что и когда cvs использовали, и когда svn, нам просто был нужен git - с ним все эти проблемы забылись как страшный сон.
     
  • 2.16, Аноним (16), 15:26, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/–
    застал cvs в начале нулевых, помню жалел после перехода на svn о потере возможности задавать периоды вида "week ago" и подобные человекочитаемые темы. Для людей делалось.
     
     
  • 3.45, Аноним (45), 17:35, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    это что-то типа git checkout "head@{1 week ago}" ?
     
  • 2.38, Аноним (38), 17:12, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/–
    RCS лусше CVS. А Новая папка (14) лучше их всех вместе взятых.
     
     
  • 3.110, Аноним (110), 03:55, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > Новая папка (14)

    Имя твоё неизвестно. Подвиг твой бессмертен.

     

  • 1.2, Аноним123 (?), 14:06, 25/09/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/–
    Её ещё использую (да и централизованные VCS в целом)? Эпоха git же, не?  
     
     
  • 2.5, Аноним (5), 14:24, 25/09/2026 Скрыто ботом-модератором     [к модератору]
  • –5 +/–
     
  • 2.11, Аноним (11), 14:54, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –3 +/–
    > Её ещё использую (да и централизованные VCS в целом)? Эпоха git же,
    > не?

    VCS и git разные вещи
    git это система обмена изменениями, почитайте на досуге какую проблему решал Линус когда писал его.
    Это как лопата и совок, просто модно молодежно вот и побежали использовать понятия не имея для чего оно. Ну в последствии дорабатывали git чтоб хоть как то сделать пригодным для работы.


     
     
  • 3.15, Аноним (14), 15:22, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/–
    Докажи О, начался спор на уровне какую задачу решал Линус 20 лет назад Прям за... большой текст свёрнут, показать
     
     
  • 4.20, Аноним (11), 15:35, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    классические - централизованные, git распределенный, потом когда git стали использовать как VCS понадобился централизованный обзор изменений - сделали githab и аналоги.
    нет смысла спорить с реальностью, не делайте так.
     
     
  • 5.30, Аноним (14), 16:49, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/–
    Я спорю не с реальностью, а спорю с безграмотными заявлениями. Но с этим спорить не буду, тут просто набор слов. Централизованность/распределённость - это просто свойства VCS, тут не надо ничего противопоставлять. А вебмордочки вообще типу VCS ортогональны.
     
  • 3.52, пох.. (?), 18:33, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/–
    > git это система обмена изменениями, почитайте на досуге какую проблему решал Линус когда
    > писал его.

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

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

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

     
     
  • 4.73, Аноним (14), 22:55, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    > Потому что других способов работы с кодом - Линус не знал и знать не хотел.  
    > И его поделка автоматизирует именно этот, никому на свете кроме него ненужный workflow.

    Время ох**тельных историй. Расскажи-ка, павлин, какие тогда были workflow приёма изменений через review кроме патчей по почте, и какие доступные VCS их умели.

     
     
  • 5.76, пох.. (?), 23:26, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > Время ох**тельных историй. Расскажи-ка, павлин, какие тогда были workflow приёма изменений
    > через review кроме патчей по почте

    спроси у команды разрарботчиков net3, как им удалось обойтись без патчей-по-почте. Или у freebsd team времен Хаббарда. Ни трака еще не было, ни фабрикатора. А большие и сложно взаимосвязанные куски кода умудрялись как-то вот разрабатывать.
    Как-то вот, удивительно, но... обходились! В почту отправлялась только... почта. Например, нотифай что кто-то закоммитил очередной кусок. Тем более что тогдашняя почта не у всех бы этот кусок вообще переварила. Ну мелкий патч ты мог конечно так кинуть, но для этого гит не нужен, достаточно diff.

    Вероятнее всего потому, что никакой review миллиона одностраничных патчей, в которые превращается любая мало-мальски сложная подсистема в чудесатом воркфлоу твоего божка, в принципе невозможен, и сводится к замене colour на color и обратно, пока божку не жалуются через личные контакты, доступные только уважаемым людям, и он чохом не аппрувит...ой, снова без ревью "патамушта у нас оказываетцо нет майнтейнера на уровне добавить-новую-фс" и все эти ревьюверы, оказывается, были просто непрошенными советчиками без прав и обязанностей.

    > и какие доступные VCS их умели.

    порезать патчи из cvs/svn и отправить в рассылку умели шелловские скрипты строк на 50.
    Которые и использовались для общения с твоим божком теми кто пользовался vcs для разработки.

    Проблема что к ревью это никакого отношения не имело, только к поклонению.

    Очевидно что ты никогда даже и не пытался отслеживать изменения ни в какой части ядра.
    (мы уже как-то раз убедились что ты даже не знаешь про оооочень специфический инструментарий, который используется для этой цели - гит, как ни изумительно, сам умеет только в одну сторону, а обратную часть божок не осилил. Видимо, его-то вполне устраивал right-click/save-as новаяпапкалинукс1.1.1 - в принципе, если самому никакой код не писать, времени на такое хватает.)

     
     
  • 6.80, Аноним (14), 23:39, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    > спроси у команды разрарботчиков net3,

    Нет, я спросил у тебя конкретно, но ты начал увиливать. Вопрос-то был риторический, потому что через почту и принимали, и именно в этот воркфлоу целился git.

    > Проблема что к ревью это никакого отношения не имело, только к поклонению

    Это твоё поклонение с нами в одной комнате? Павлин, я тебе ещё 5 лет назад, когда ты вандалил OSM, сказал: прекрати пить. Ещё не поздно, потому что сейчас ты несёшь не больший бред чем тогда.

     
     
  • 7.87, пох.. (?), 23:49, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    блин, да никто ничего не принимал через почту кроме однострочников. Такой индивидуй был - один. И даже в его же проекте отдельные команды использовали - svn, а не патчи через почту.

    ты опоздал родиться,но как всегда - врешь, выдавая свои фантазии за знания.


     
     
  • 8.89, Аноним (14), 23:56, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    А ничего что ядро уже несколько десятков лет ТОЛЬКО через почту и разрабатываетс... текст свёрнут, показать
     
     
  • 9.104, пох.. (?), 01:23, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    мда тут комментировать - только портить Ты ведь во всех вещах такой же специал... текст свёрнут, показать
     
  • 2.19, Аноним (19), 15:29, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/–
    По-прежнему отличный вариант для *централизованной* VCS. Это если вы понимаете разницу. А если не понимаете - то и сидите на git.
     
     
  • 3.21, Аноним10084 и 1008465039 (?), 15:37, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +4 +/–
    Вот только смысл в строго централизованной VCS, если git абсолютно так же можно использовать квазицентрализованно? Зато если вдруг понадобиться децентрализация, она сразу будет из коробки.

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

     
     
  • 4.106, Аноним (106), 03:27, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Ну и как, к примеру, просмотреть лог ветки, не клонируя её, не делая fetch, и не прибегая к внешним инструментам типа веб-интерфейсов?
     
  • 3.31, Аноним (14), 16:50, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Так git можно использовать централизованно, никакого требования именно централизованной VCS нет и никогда не было. Есть конкретные требования некоторых свойств которые CVCS исторически обеспечивают лучше, типа отдать кусок репозитория или не отдавать всю историю.
     
     
  • 4.42, Аноним (45), 17:28, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –2 +/–
    Может чел просто любит страдать в духе "я залочу этот файл чтобы никто в команде работать не мог и свалю в закат, а ещё у меня регулярно не работает Инет, поэтому разлочить я его смогу когда-нить потом, если раньше не отправят на фарш"
     
  • 2.35, Сладкая булочка (?), 17:03, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    git не тянет большие размеры репозиториев.
     
     
  • 3.39, Аноним (14), 17:15, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    В чём именно это выражается Помню миграцию FreeBSD с svn на git - там git клон ... большой текст свёрнут, показать
     
     
  • 4.44, Аноним (44), 17:31, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    Для полноценной работы гиту надо качнуть всю репу со всей историей. Дедубликация тоже посредственная. Если в репе много бинарей, то она раздувается. Частично спасают всякие костыли, вроде pristine-lfs.
     
     
  • 5.51, Аноним (14), 18:23, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Репозитории больших размеров, про которые изначально шла речь != репозитории с бинарными блобами. Репозитории больших размеров git тянет замечательно, я про это расписал. А блобы у которых между ревизиями меняется чуть более чем всё (а почти все блобы такие), не задедуплицирует вообще ничто. Всю историю git может не тянуть, итого из кейсов которые git "не тянет" остаётся только когда нужно вытянуть кусочек репы, и да - это решается отдельными инструментами, равно как и с svn, который тоже не умеет виртуальную файловую систему из коробки.
     
     
  • 6.53, Аноним (44), 18:43, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/–
    >это решается отдельными инструментами, равно как и с svn

    Это какими же, интересно? svn checkout после обрыва спокойно докачивается через svn update. git это как не умел, так и не умеет.

    >про которые изначально шла речь != репозитории с бинарными блобами

    Они и становятся большими по причине, что оно не умеет работать с блобами

    > Репозитории больших размеров git тянет замечательно, я про это расписал

    При обрыве качает всё сначала. Это называется "не тянет". Если репа по 500мб, то готовь гигабитный интернет. Иначе оно не умеет.

     
     
  • 7.58, Аноним (14), 20:05, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Я уже сказал, виртуальными фс А с ними никто не умеет работать Большинство бин... большой текст свёрнут, показать
     
     
  • 8.64, Аноним (44), 21:33, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Какими Из коробки этого у гита нет svn же позволяет продолжить с любого места ... текст свёрнут, показать
     
     
  • 9.74, Аноним (14), 23:10, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    git-lfs, а для svn ничего похожего нет Нет, это не про докачку, следи за дискус... большой текст свёрнут, показать
     
     
  • 10.101, Аноним (44), 00:18, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Костыль В этом и проблема Точнее много проблем, но ты почему-то уверен, что эт... большой текст свёрнут, показать
     
  • 5.103, penetrator (?), 01:01, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    The "scalar" addition from Microsoft is now part of the core Git installation.

    2.38.0

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

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

     
  • 4.50, Сладкая булочка (?), 18:22, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > В чём именно это выражается? Помню миграцию FreeBSD с svn на git
    > - там git клон (чекаут + вся история) весил меньше чем
    > svn (только чекаут одной ревизии), сам клон выполнялся на порядок быстрее
    > (во многом за счёт меньшего насилия над диском), а операции над
    > ним (коммит, смена ветки, лог, блейм) выполнялись мгновенно, а не минутами
    > как в svn.

    Монорепы больше 10Гб.

    > svn технически может "тянуть" что-то лучше только в одном случае - когда
    > ты чекаутишь небольшой кусочек репозитория. Честно говоря, даже не знаю репозиториев
    > где кусочек без целого будет представлять какой-то интерес, но допускаю что
    > такое бывает.

    В монорепах такое часто нужно. Скажем твоему проекту нужны только определенные библиотеки.

    > Есть огромные репозитории которые git действительно "не потянет", типа монореп гугла или
    > микрослопа. Но svn "не потянет" даже 1/100 от них,

    git'у плохо уже на 10Гб, svn прекрасно тянет.


    > там для работы используются виртуальные файловые системы подрягивающие контент on-demand. Но cli к ним всё равно повторяет git, в ms по крайней мере.

    Утиная типизация тут неприменима. Это не git.

     
     
  • 5.55, Аноним (14), 18:58, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Ну репы в 20Гб у меня есть, там базовые операции типа commit checkout log происх... большой текст свёрнут, показать
     
     
  • 6.60, Сладкая булочка (?), 20:49, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Есть мнение, что ветками в svn пользоваться не надо В svn ты можешь счекаутить... большой текст свёрнут, показать
     
     
  • 7.75, Аноним (14), 23:20, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    Согласен Это никак не противоречит тому что svn пользоваться не надо Я знаю, я... большой текст свёрнут, показать
     
  • 4.61, Сладкая булочка (?), 21:03, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > Помню миграцию FreeBSD с svn на git

    Там размеры репозитория скромные.

     
     
  • 5.65, Аноним (44), 21:35, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Даже больше. гит там используется в режиме одной ветки. Т.е. по сути работает как svn.
     
     
  • 6.70, Сладкая булочка (?), 21:46, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > Даже больше.

    Полный клон - 1.45 GiB по сети. https://vermaden.wordpress.com/2026/01/10/add-port-to-freebsd-ports/

     
     
  • 7.79, Аноним (14), 23:33, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Да не важно, я утверждаю что и с такой репой в svn работать комфортно невозможно, потому что на своей шкуре это испытал пока FreeBSD наконец не переехала на git. Хочешь доказать обратное - выложи git и svn рядом на одном хосте, а мы посмотрим сколько там занимают типовые операции.
     
     
  • 8.99, Аноним (44), 00:09, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/–
    Работает всё Никакой разницы нет Ну разве что в гит нет докачки ... текст свёрнут, показать
     
  • 3.40, Аноним (38), 17:15, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Большие -- это сколько в байтах? Майкрософт и Гугл знают об этом? (Я знаю, что знают, но вот с какого размера начинаются неудобства тут знает приблизительно никто, потому что ни у кого здесь столько кода нет).
     
     
  • 4.43, Аноним (44), 17:29, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/–
    докачки до сих пор нет. Если git pull отвалился, то качай заново.
     
  • 4.49, Сладкая булочка (?), 18:19, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > Большие -- это сколько в байтах? Майкрософт и Гугл знают об этом?

    На 10Гб уже плохо. У Гугла свой монорепозиторий.


     
     
  • 5.56, Аноним (14), 19:04, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    У гугла проприетарное поделие под названием perforce, над которым у них своя нашлёпка связанная с билд системой, что позволяет, когда ты хочешь собрать бэкенд например, карт, зачекаутить только то что он по зависимостям требует. Такое ни одна из обычных vcs не осилит, но пользоваться perfoce было адовым адом.
     
     
  • 6.59, Сладкая булочка (?), 20:24, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > У гугла проприетарное поделие под названием perforce, над которым у них своя
    > нашлёпка связанная с билд системой, что позволяет, когда ты хочешь собрать
    > бэкенд например, карт, зачекаутить только то что он по зависимостям требует.
    > Такое ни одна из обычных vcs не осилит, но пользоваться perfoce
    > было адовым адом.

    Они вроде им с 15 года не пользуются? Посыл один: большие монорепы git не выдерживает, поэтому у всех свои костыли.

     
     
  • 7.66, Аноним (44), 21:36, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Да, в дебиане например pristine-lfs для хранения тарболов. Но от тоже жуть, какой неудобный.
     
     
  • 8.90, пох.. (?), 23:58, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    потому что это костыль, ломающий собственно смысл vcs - все, что ты туда положил... текст свёрнут, показать
     
     
  • 9.98, Аноним (44), 00:07, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Который сделали для решения проблем с гитом Второй костыль это модули Тоже кри... текст свёрнут, показать
     
     
  • 10.102, пох.. (?), 00:22, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    ну блин, других разработчиков уже нет Раз уж даже ms которая как минимум не ... текст свёрнут, показать
     
  • 7.77, Аноним (14), 23:28, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > Посыл один: большие монорепы git не выдерживает

    Нет, посыл не такой. Посыл - большин монорепы не выдерживает ни git ни svn.

    > поэтому у всех свои костыли.

    Почему ты употребляешь слово "костыли"? Какое, по-твоему, некостыльное решение работы с репозиторием в 1Тб на 10 миллиардов файлов, если тебе из него нужно 1%, но ты наперёд не знаешь пути, которые нужны?

     
     
  • 8.93, пох.. (?), 00:02, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Узнать у кого-то кто знает, какие нужны И скачать только нужные Для этого у но... текст свёрнут, показать
     
  • 8.109, Сладкая булочка (?), 03:38, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Я не защищаю svn Просто спрашивали про git Но svn подольше продержится для мон... текст свёрнут, показать
     
  • 4.107, Аноним (19), 03:29, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Необходимость скачать даже 100МБ не нужной мне истории или кода - уже много.
     

  • 1.3, Аноним (3), 14:17, 25/09/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/–
    Настоящие программисты Git не используют.
     
     
  • 2.4, Аноним (4), 14:22, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +4 +/–
    Ага, настоящие пограмисты хранят распечатки на бумаге ;)
     
     
  • 3.6, Аноним (6), 14:42, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/–
    > на бумаге

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

     
  • 3.8, Аноним (8), 14:50, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    потому что настоящие программисты пишут сразу настоящий продукт. без версий, без истории написания
     
     
  • 4.92, Аноним (92), 00:01, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Это растопрограммисты?
     
  • 3.27, Оно ним (?), 16:20, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    https://semicolon.trm.sh/
     
  • 2.7, Гуманоид (?), 14:50, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    Git - это сильно раздутая консольная утилита для работы с гитхабом. Для работы есть более вменяемые инструменты.
     
     
  • 3.9, Аноним (8), 14:52, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    любая утилита для работы с дутым хабом будет сама по себе раздутой
     
  • 2.10, Аноним10084 и 1008465039 (?), 14:52, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    Вместо этого они используют BitKeeper :) Это просто у одного финского в-то-время-нестудента не хватило денег на лицензию, вот он и накостылял на коленке git
     
     
  • 3.25, Аноним (25), 15:52, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/–
    И ъорошо, что не хватило. В результате, теперь все могут свободно и бесплатно пользоваться Git.
     
     
  • 4.36, Сладкая булочка (?), 17:04, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Делаем вывод: фину не надо платить)
     
     
  • 5.94, Аноним (92), 00:03, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    За выкрутасы последних лет, начиная с выпиливания прокрутки консоли, точно не надо.
     
  • 3.96, пох.. (?), 00:05, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > Вместо этого они используют BitKeeper :) Это просто у одного финского в-то-время-нестудента
    > не хватило денег на лицензию,

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

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

     
     
  • 4.105, Аноним10084 и 1008465039 (?), 01:24, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Историю я перечитал перед тем, как постить, да. А ещё смешно, что отозвали у Линуса эту "бесплатную" лицензию потому, что Эндрю Триджелл отреверсил протокол биткипера, чтобы извлекать данные из него. Тот самый Триджелл, который недавно прославился нейрослопом и последовавшими за ним багами в rsync.
     

  • 1.12, Метрика (?), 15:02, 25/09/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/–
    Учитывая каким монстром стал git, на его фоне svn выглядит очень даже ничего
     
     
  • 2.17, Аноним (14), 15:27, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    И каким же монстром он стал? Так-то svn тяжелее

    SIZE (subversion-1.14.5.tar.bz2) = 8675355
    SIZE (git-2.55.0.tar.xz) = 8177180

    при том что тащит за собой ещё и апачевскую помойкобиблиотеку apr, и даже в https не умеет без внешней библиотеки (ещё один костыль serf).

     
     
  • 3.24, Аноним (24), 15:52, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    Так там ещё полноценный сервак есть.
     
     
  • 4.32, Аноним (14), 16:51, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Сервак везде есть, и весит он копейки.
     
     
  • 5.54, Аноним (44), 18:44, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    В гите его нет. Работает поверх ssh
     
     
  • 6.82, Аноним (14), 23:40, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    Есть, работает не только поверх ssh. Достаточно запустить и в nginx сделать proxy_pass.
     
     
  • 7.97, пох.. (?), 00:07, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > Есть, работает не только поверх ssh. Достаточно запустить и в nginx сделать
    > proxy_pass.

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

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

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


     
  • 2.18, fatlortroll (?), 15:28, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Fossil-же, ну!
     
     
  • 3.37, Аноним (14), 17:05, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    Интересно что человек, в мирке которого git "стал монстром" и вообще тяжелее svn, скажет о поделке со встроенными сайтом, issue трекером, рьвьюшницей, вики, базой данных и ещё бог весть чем.
     

  • 1.22, Вася Пупкин (?), 15:44, 25/09/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/–
    Зачем это устаревшая система контроля версий, если есть Git ?
     
     
  • 2.23, Пыщь (?), 15:50, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/–
    "Больше всего я жалею не о деньгах, а о том, что Git — это просто жалкое подобие SCM. Меня сводит с ума, что его модель представляет собой сервер с тарболами. Даже Линус признал мне, что это дерьмовый дизайн. Он делает так, как считает нужным, — но это вовсе не значит, что весь мир должен считать так же." (кажется, цитата)
     
  • 2.29, xsignal (ok), 16:27, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Git нужен только для проектов, типа ядра Linux, а использовать его в небольших и средних проектах с малым числом разработчиков - это стрелять из пушки по воробьям - избыточно, неудобно, сложно, а svn здесь - самое то.
     
     
  • 3.33, Аноним (14), 16:59, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    > стрелять из пушки по воробьям - избыточно, неудобно, сложно, а svn здесь - самое то.

    Очень странные мысли, вы видимо VCS никогда не пользовались, и проекты не разрабатывали. Как раз для небольших проектов git сильно легче и удобнее, потому что git init и можно коммитить. Никаких svnadmin, никаких выделенных серверов под репозиторий, никаких проблем если локально созданный репозиторий вдруг захотелось куда-то выложить (при этом что сейчас и некуда). И в чём избыточность? Функциональность которой вы не пользуетесь не жрёт ни CPU, ни места на диске, ни токенов, ни ваших нейронных связей, а когда она понадобится, она у вас будет, и не надо будет конвертить репозиторий из древнего централизованного недоразумения в полноценную vcs.

     
     
  • 4.71, А ноним (?), 22:01, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Вот только трындеть не надо, свн прекрасно работает без серверов, репа создаётся в указанном месте на локальной ФС, после чего "клиент" svn прекрасно с ней работает в 1 харю.

    "git через ssh" вощем-то тоже работает сервером (сам git на удалённой репе). При этом искаробки там разделение доступа вообще не предусмотрено (несмотря на ssh), и для разделения доступа безусловно нужны сторонние тулы типа gitolite.
     
     
  • 5.83, Аноним (14), 23:42, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    > Вот только трындеть не надо, свн прекрасно работает без серверов, репа создаётся в указанном месте на локальной ФС, после чего "клиент" svn прекрасно с ней работает в 1 харю.

    Ты хоть читал на что отвечаешь? Я ровно весь процесс создания локального репозитория svn для 1 хари расписал, а также расписал насколько в git он удобнее.

     
  • 3.81, limafresh (ok), 23:40, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    > использовать его в небольших и средних проектах с малым числом разработчиков - это стрелять из пушки по воробьям

    Ну да, конечно. Поднимать сервер с "удобной" SCV конечно "проще", и наверное не требует специальных навыков и денег на хостинг (нет), чем создать репозиторий на GitHub или подобном сервисе по нажатию кнопки. Зато не git. Странно, что люди не понимают, что SCV - это не программа, которую можно выбирать, а инструмент для загрузки кода в онлайн-сервис, и какая там есть, такая и есть.

     
     
  • 4.84, Аноним (14), 23:44, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/–
    > Ну да, конечно. Поднимать сервер с "удобной" SCV конечно "проще", и наверное не требует специальных навыков и денег на хостинг (нет), чем создать репозиторий на GitHub или подобном сервисе по нажатию кнопки

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

     
  • 2.34, Аноним (14), 17:02, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Прежде всего для заброшенного легаси, которое в git конвертить уже некому и незачем, но исходники достать нужно. В редких случаях для специфичных кейсов типа версионирования 3D ассетов (текстур, сцен, моделей), хотя наверняка для этого есть более подходящие инструменты.
     
  • 2.62, tkzv (ok), 21:06, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Для собственных заметок.
     

  • 1.41, Аноним (45), 17:21, 25/09/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/–
    Когда они уже поддержат работу с Git? А то как-то не честно, git-svn есть, а svn-git нету
     
  • 1.47, вах (ok), 17:45, 25/09/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/–
    Теперь новые версии можно выпускать каждый час!
     
  • 1.57, zionist (ok), 19:43, 25/09/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/–
    Git - это так же централизованная система хранения версий. По крайней мере только централизованно Git и используется. Лишите любой проект доступа к центральному сереверу на GitHub и к его аналогам и проект умрёт.
     
     
  • 2.67, Аноним10084 и 1008465039 (?), 21:37, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Социально да, но технически нет. В svn если центральный сервер помрёт, насколько я понимаю, история того. Разве что рабочие копии останутся на руках. А в git у каждого по сути готовая полноценная репа с историей (если выкачивал)
     
     
  • 3.69, Аноним (44), 21:42, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    svn позволяет коммитить в локальную репу. Сделать синхронизацию не проблема, только никому это не надо.
     
     
  • 4.88, Аноним (14), 23:53, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > Сделать синхронизацию не проблема, только никому это не надо.

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

     
     
  • 5.91, Аноним (44), 00:00, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > что зеркалирование репозитория, так что в него нельзя будет коммитить.

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

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

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

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

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

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

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

     
  • 2.68, Аноним (44), 21:40, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    Да, так и есть. Синхронизации между репами без центрального сервера там не предусмотрено.
     
  • 2.72, Сладкая булочка (?), 22:12, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/–
    > Лишите любой проект доступа к центральному сереверу на GitHub и к его аналогам и проект умрёт.

    Формально нет. Отвалятся баг репорты, пулл реквесты, CI, но код можно с любой копии взять. Но на практике да: хипстеры начнут ныть, что работать невозможно, а локально собрать проект у них лапки.

     
     
  • 3.78, Джон Титор (ok), 23:31, 25/09/2026 Скрыто ботом-модератором     [к модератору]
  • –1 +/–
     
  • 3.85, пох.. (?), 23:44, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/–
    >> Лишите любой проект доступа к центральному сереверу на GitHub и к его аналогам и проект умрёт.
    > Формально нет. Отвалятся баг репорты, пулл реквесты, CI, но код можно с

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

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

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

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

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

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

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


     
  • 2.86, Аноним (14), 23:48, 25/09/2026 [^] [^^] [^^^] [ответить]  
  • +/–
    > Git - это так же централизованная система хранения версий. По крайней мере только централизованно Git и используется.

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

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

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

     
     
  • 3.95, Аноним (44), 00:04, 26/09/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/–
    >git это децентрализованная система хранения версий

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

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

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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