Организация Apache Software Foundationпредставила (https://blogs.apache.org/foundation/entry/the-apache-softwar...) релиз системы управления версиями Subversion 1.11.0 (http://subversion.apache.org). Несмотря на развитие децентрализованных систем, Subversion продолжает пользоваться популярностью в коммерческих компаниях и проектах, использующих централизованный подход к управлению версиями и конфигурацией программных систем. Из использующих Subversion открытых проектов можно отметить: проекты Apache, FreeBSD, Free Pascal, OpenSCADA, GCC и LLVM.
Выпуск примечателен переходом к фиксированному циклу разработки. Новые ветки теперь будут формироваться раз в полгода. Раз в два года ветке будет присваиваться статус выпуска с длительным сроком поддержки (LTS). Обычны выпуски будут поддерживаться 6 месяцев до момента формирования следующего значительного выпуска. LTS-ветки будут поддерживаться 4 года. Выпуск Subversion 1.11 отнесён к обычным выпускам, а прошлой версии Subversion 1.10 присвоен статус LTS. Следующим LTS-релизом станет версия Subversion 1.14, которую планируют выпустить в апреле 2020 года.Ключевые улучшения (https://subversion.apache.org/docs/release-notes/1.11.html) Subversion 1.11:
- Добавлена экспериментальная возможность сохранения слепков состояния коммитов ("commit checkpointing"), позволяющая сохранить снапшот изменений, еще не зафиксированных коммитом, и позднее восстановить в рабочей копии любую из сохранённых версий изменений. Новая функция предоставляет разработчикам возможность откатить состояние рабочей копии в случае ошибочного обновления;
- Повышена надёжность экспериментальных команд "svn x-shelve/x-unshelve/x-shelves", позволяющих отдельно отложить незавершенные изменения в рабочей копии, чтобы срочно поработать над чем-то другим, а затем вернуть недоделанные изменения в рабочую копию. В новой версии добавлена поддержка слепков состояния для сохранения нескольких версий изменения, реализована поддержка бинарных файлов, изменён формат хранения изменений, увеличена надёжность возврата изменений в рабочую копию в ситуации её обновления. Добавлены новые команды x-shelf-diff, x-shelf-drop, x-shelf-list, x-shelf-list-by-paths, x-shelf-log и x-shelf-save;- Интерфейс интерактивного разрешения конфликтов расширен поддержкой ситуаций возникновения конфликтов из-за перемещения файлов и каталогов. Например, теперь поддерживается разрешение большинства конфликтов, связанных с потерей элементов в результате их перемещения после слияния исходной ветки;
- Добавлена новая команда "svn info --x-viewspec" для вывода спецификации, описывающей текущую рабочую копию. Описание включает информацию об ограничении глубины подветок, исключении подветок, переключении на другой URL или обновлении до нового номера ревизии, по сравнению с родительским каталогом;
- Добавлена возможность сохранения пароля к клиентскому сертификату;
- Обновлён биндиг JavaHL, в котором обеспечена совместимость с Java 10. Для сборки JavaHL теперь требуется как минимум Java 8.
URL: https://blogs.apache.org/foundation/entry/the-apache-softwar...
Новость: https://www.opennet.ru/opennews/art.shtml?num=49529
Неплохо. Но чем он лучше ПИЖУЛЯ? (pijul)
А чем она лучше гита? Тем что вокруг неё нет ни инструментов, ни хостинга нормального, ни сообщества, ни биндингов к питону, ни графического интерфейса, ни взаимодействия с гитом, ни даже некстгена нормального, при этом сами коммиты занимают больше места?
Ну, например, тем, что, в отличии от гита, для удобности SVN всё вышеперечисленное не необходимо.
да-да, особенно вот это изменение:
> Интерфейс интерактивного разрешения конфликтов расширен поддержкой ситуаций возникновения конфликтов из-за перемещения файлов и каталогов.
Это при условии что вы установите себе gui-евого клиента. А гитов можно и из консоли без всяких проблем.
Опять тёплое с мягким.
Что, правда что-ли?
Это лишь один из примеров guikdesvn-kde4-1.7.0_10
Name : kdesvn-kde4
Version : 1.7.0_10
Installed on : Wed Oct 3 06:21:10 2018 MSK
Origin : devel/kdesvn-kde4
Architecture : FreeBSD:11:i386
Prefix : /usr/local
Categories : kde devel
Licenses : GPLv2+
Maintainer : kde@FreeBSD.org
WWW : https://projects.kde.org/projects/extragear/sdk/kdesvn
Comment : KDE frontend for Subversion
> А чем она лучше гита? Тем что вокруг неё нет ни инструментов, ни хостинга нормального, ни
> сообщества, ни биндингов к питону, ни графического интерфейса, ни взаимодействия с гитомво, отлично сформулировал, возьму на память (кроме графического интерфейса, который как раз one-true tortoise svn, а не косорукие клоны, как для гита/hg)
именно этим и лучше - рукожoпы, альтернативно одаренные и девляпсы сразу строем идут нахрен от непонятной им конструкции, и не имеют возможности осчастливить "недостаточно продвинутые" проекты своим гуанокодом.
к тому же 'сообщества' тоже нет, и чятика/сосальной сеточки для посасывания друг-дружке тоже нет, на голову больным, коммитерам в .md, снова негде развернуться.
отличный фильтр, оставляющий только тех кто умеет освоить несложный инструмент и работать, а не "расставлять теги".
Все можно проше сделать: обязать разработчиков писать код в ваш проект от руки. На глиняных табличках, как вавилоняне. Отсутствие рукожопов в проекте гарантирую.
Частичный update репозитория. У git'а и hg такой фичи не нашёл.
> commit checkpointingПопытка переизобрести гитовый index?
Не уверен. Тем более, что, судя по описанию, здесь можно сделать несколько checkpoint, в отличие от git index, где оно или в индексе, или нет.
тогда git stash
> тогда git stashУже ближе, да. Но у git stash другая семантика, из-за чего он убирает изменения из рабочей ветки — а данная фича Subversion больше похожа на, как ни смешно, на git commit.
> GCC и LLVM.Которые, между прочим, активно свинчивают на git. Потому что разработчики нынче склонны ожидать более вменяемые VCS и использование апач-архаики сильно нагибает процессы разработки.
Конечно, какому-нибудь замшелому корпоративному болоту в режиме майнтенанса и так сойдет, а живым опенсорсным проектам - опачки.
У кого там что нагибает? Если проект в морг, то гит ему не поможет.
Если проект использует svn вместо git'а, его шансы на посещение морга в обозримом будущем весьма существенно возрастают, имхо.
если парк таксомоторной компании целиком и полностью не состоит из автомобилей марки «БМВ», то шансы на то, что такая компания в скором времени загнётся очень велики...
Если у человека волосатые ноги - его шансы на посещение стоматолога в обозримом будущем весьма существенно возрастают, имхо.
Если человек носит красные ботинки, то у него шансы попасть под машину существенно возрастают, имхо.
> а живым опенсорсным проектам - опачки.Так в этом их главное отличие, SVN полагает, что разработчик вменяемый человек, а git больше заточен на то, чтоб мантейнер в куче ... искал жемчужины. А для разработчика в нормальной ide не особо то и заметно, какая там версионка под капотом.
сидишь ты такой корячишь новую функцию и тут прилетает баг:
1. срочно делаешь svn commit
2. переключаешься на ветку trunk
3. готовишь исправление и делаешь svn commit
4. переключаешься на свою ветку с новым функционалом и готовишь следующий коммит, который починит предыдущий
Ну если за количество коммитов и починенных багов платят поштучно, то почему бы и нет.А так-то новость про всякие shelve.
P.S. Для быстрого исправления можно было и раньше и отдельную папку для trunk держать, коммитить ради этого разваленный билд было не обязательно. Но, как я уже писал выше - у svn чересчур завышенные требования к адекватности разработчика. :)
Что за идиотская мода выпускать минорные релизы с мажорным обновлением цифр в версиях? Вот почему нельзя это было выпустить как 1.10.4? Там ведь формат не поменялся (только для экспериментальных shelves). А вот следующую 1.14 LTS выпустить как 1.11. Дурдом какой-то...
Теперь у нас одни мажорные версии (LTS) мажорнее других мажорных. Прям Оруэл
> Что за идиотская мода выпускать минорные релизы с мажорным обновлением цифр в
> версиях? Вот почему нельзя это было выпустить как 1.10.4? Там ведь
> формат не поменялся (только для экспериментальных shelves). А вот следующую 1.14
> LTS выпустить как 1.11. Дурдом какой-то...это имхо тянет на мажорные изменения, может даже вообще первую цифру надо было поднять
> Интерфейс интерактивного разрешения конфликтов расширен поддержкой ситуаций возникновения конфликтов из-за перемещения файлов и каталогов. Например, теперь поддерживается разрешение большинства конфликтов, связанных с потерей элементов в результате их перемещения после слияния исходной ветки;
Удивительно, что GCC до сих пор не перешёл на Git.
> Удивительно, что GCC до сих пор не перешёл на Git.БольшИИИе коммиты [пере]ходить мешают.
Танцорам, эрикам и пр.хирургам.
И питон! Нп голанг уповают.
"" The proximate cause of the move is that reposurgeon hit a performance wall on the GCC Subversion repository. 259K commits, bigger than anything else reposurgeon has seen by almost an order of magnitude; Emacs, the runner-up, was somewhere a bit north of 33K commits when I converted it. ""
--http://esr.ibiblio.org/?p=8161
Потому, что esr не использует православный svn2git и пишет свой велик на пайтоне.
>не использует православный svn2gitУгу, смешная шутка.
а чего с ним, кстати, не так? Я пользуюсь, правда, в одностороннем порядке - в то репо никто кроме меня не коммитит, поэтому мне не надо оттуда в svn. Но вроде бы и с этим проблемы у него нет.
А в чем разница
"commit checkpointing" - ... позволяющая сохранить снапшот изменений, еще не зафиксированных коммитом, и позднее восстановить в рабочей копии
и
"svn x-shelve/x-unshelve/x-shelves", позволяющих отдельно отложить незавершенные изменения в рабочей копии
?P.S. похоже на "git stash"
Чекпоинт это точка куда можно откатиться.
Ракушка - это полочка, куда откладываются изменения, чтоб потом накатить их вновь от какой-то точки.
Насколько я понимаю
svn commit создает на сервере номер ревизии - точку куда можно откатиться выполнив svn update -r
?Что делает "commit checkpointing"? Какую-то "локальную ревизию"? Особый номер ревизии на сервере?
shelve и есть stash (ну или точнее hg shelve)а checkpoint это песни на тему rebase, по сути, только без образования мертвых "невидимых" веток.
Не могу не поделиться: Git for Victims of Subversion
> Не могу не поделиться: Git for Victims of Subversion
> https://www.nobleprog.com/cc/gitvicsubv/Гадость, какая. Зарабатывать на братьях наших с ограниченными возможностями?!
"7 часов"?... Смотреть https://www.youtube.com/watch?v=4XpnKHJAok8 по кругу, пока сабж не отвалится, а git не начнёт "отскакивать от пальцев". За _шесть_ (1:10 в 7:00!) полных кругов по кругу должно сработать по-любому.
---Всем https://www.youtube.com/results?search_query=torvalds+git чаю.
..."if there are SVN users, Subversion users in the audience, you MIGHT WANT to leave"... (c) LT, там--^^ же, 0:03:14
не думаю, что он свои услуги так рекламировал, просто название курса смешное