После почти трёх лет разработки состоялся (https://svn.haxx.se/dev/archive-2018-04/0040.shtml) релиз новой ветки системы управления версиями Subversion 1.10.0 (http://subversion.apache.org). Несмотря на развитие децентрализованных систем, Subversion продолжает пользоваться популярностью в коммерческих компаниях и проектах, использующих централизованный подход к управлению версиями и конфигурацией программных систем. Из использующих Subversion открытых проектов можно отметить: проекты Apache, FreeBSD, Free Pascal, OpenSCADA, GCC и LLVM.Ключевые улучшения (http://subversion.apache.org/docs/release-notes/1.10):
- Представлена новая реализация механизма (http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbase...) авторизации на основе путей, дающего возможность определить правила доступа к отдельным каталогам в репозитории. Помимо ранее предлагаемых правил
"[repos:/path]" (с привязкой к репозиторию) и "[/path]" (глобальные проверки), которые допускают только точные совпадения путей, новая реализация позволяет использовать два новых формата "[:glob:repos:/path]" и "[:glob:/path]", допускающих использования масок. Для создания масок предлагается использовать классические маски вида *foo*.bar, а также конструкции "/*/" для сопоставления с одним (только одним) сегментом пути и "/**/" для сопоставления с произвольным числом сегментов;- Полностью переработана интерактивная система разрешения конфликтов, которая ищет в истории репозитория структурные изменения (операции добавления, удаления, копирования и перемещения), которые конфликтуют с локальными изменениями в рабочей копии и приводят к образованию дерева конфликтов. В новой реализации дерево конфликтов снабжено детальными сведениями, которые раньше приходилось искать вручную, в том числе указаны номера ревизий и имена разработчиков конфликтующих изменений. Новая система также научилась определять операции перемещения и переименования в истории репозитория и учитывать их при изменении локальной рабочей копии, что сделало процесс слияния между ветками максимально прозрачным, в случае если в одной или в обеих ветках выполнялись операции переименования файлов или каталогов. Конфликты которые имеют однозначное решение теперь по возможности разрешаются автоматичести, без запроса пользователя (например, когда файл перемещён в другое место репозитория);
- Добавлена поддержка механизма сжатия LZ4, в качестве альтернативы ранее предлагавшейся системе zlib. LZ4 существенно превосходит zlib по скорости сжатия и распаковки, сохраняя при этом приемлемую степень сжатия. Как результат, переход на LZ4 позволяет существенно увеличить производительность операций чтения и записи, особенно если репозиторий включает большие файлы. Поддержка LZ4 включена по умолчанию для сжатия данных в репозитории (версия формата хранилища 8, для обновления можно использовать "svnadmin upgrade"), а также применяется для сжатия трафика при доступе к внешнему репозиторию по "http://" и "svn://";
- Добавлены экспериментальные команды "svn shelve/unshelve/shelves", позволяющие отдельно отложить незавершенные изменения в рабочей копии, чтобы срочно поработать над чем-то другим, а затем вернуть недоделанные изменения в рабочую копию. Поведение предлагаемой возможности похоже на сохранение созданного через "svn diff" патча с последующим его восстановлением через "svn patch";
URL: https://svn.haxx.se/dev/archive-2018-04/0040.shtml
Новость: https://www.opennet.me/opennews/art.shtml?num=48444
Это типа git ?
Да, только централизованный.
Это типа CVS.
> Из использующих Subversion открытых проектов можно отметить: ... GCC
Но это всего лишь зеркало:
description Mirror of all GCC SVN branches and tags
Время от времени эта ерунда всплывает на работе, а все уже забыли, как ею пользоваться. Ржом и гуглим.
Что там гуглить то? Практически также как и CVS.
Пользоваться надо вот так:
https://git-scm.com/docs/git-svn
Она как раз простейшая в использовании. В дереве разобраться и все. В нем и теги, и все сразу наглядно.
хорошая vcs, жаль не в трендах
боюсь спросить, как же тогда выглядят плохие?http://www.robgonda.com/blog/index.cfm/2007/10/19/SVN-PROPFI...
o-Such-Revision(это чуваку повезло, на самом деле нет никаких вариантов выяснить, какая версия на самом деле последняя, можно только угадать, на какую откатываться, но никак не узнать, не потерял ли ты данные)
http://stackoverflow.com/questions/13031544/empty-or-non-exi...
-in-a-subversion-repository
(ну тут просто, "any 64value will work", правда, пока ты с этим разбираешься, репо не работает)
и да, угадайте, почему я знаю о существовании этих статей.про неработающий svn log в частично permissionless/частично нет (в public части репо) я уж молчу, право, какая мелочь.
(да, я понимаю, что модные-современные и такого-то не умеют)
это какие-то кастомные проблемы (первая ссылка битая, вторая давно пофикшена, судя по твоей же ссылке), за много лет работы не сталкивался.
мне неудобства доставляет только отсутствие .svnignore. управлять игнорами на уровне хуков неудобно.
svn:ignore вроде свойство же
> svn:ignore вроде свойство жеоно per-dir, и не наследуется, это уж точно вредная фича (потому что ее вообще не видно, если не знать что оно тут используется)
можно такой же список держать в config, но он, естественно, будет твой личный, а не в репо.
Если нужно чтобы автоприлетало каждому Васяну, вчера получившему туда доступ, пока он не накоммитил чего лишнего - не вариант.
я и говорю неудобно
> это какие-то кастомные проблемыэто банальное последствие приземления сервера не на все четыре лапы (в моем случае старательно отваливалась hp 3par - "за много лет работы" я тоже не сталкивался, что san'овская хранилка вот она есть, но ее - нет. А оно, вот...)
Удивительная структура svn'овского репо оказалась на редкость уязвимой к крэшам и практически не имеющей средств починки. А поскольку это нифига не distributed vcs - геморрой обеспечен.нате вам обе ссылки, защищенные от местных странных парсеров:
https://tinyurl.com/yb568dea
https://tinyurl.com/mqnmokr> мне неудобства доставляет только отсутствие .svnignore. управлять игнорами на уровне хуков
> неудобно.по-моему так и наоборот, там их видно, вместе со всей остальной местной спецификой, в отличие от файла о котором все время надо отдельно помнить. Но для моих целей оно вообще очень редко нужно.
(то есть, собственно, единственный частоиспользуемый мной ignore - * - поскольку это мой хомяк)А вот ситуация когда мы держали-держали развесистое дерево репо, а потом внезапно решили часть его попрятать хотя бы под svn permissions - случалась. Оно при этом как-то работает, но изрядно странно.
не знаю как выглядят плохие, у меня опыт ограничен git/mercurial/svn. у всех есть плюсы-минусы.
> боюсь спросить, как же тогда выглядят плохие?Плохие выглядят примерно так же, только в серверную часть встроена неудобная веб-морда с баг-трекером и виками.
Как плохие выглядят монорепы на гите.
> хорошая vcs, жаль не в трендахИменно как vcs subversion днище, но ничётак в качестве версионированной фс для файловой помойки - так её обычно и используют.
вобщем да, но зачастую этого и достаточно.
нет, недостаточно. В разработке, т.е. где нужна именно vcs, недостаточно даже hg.
А чем hg то недостаточно со всеми стандартными плагинами? Все то же, что и в гите, можно сделать.
Нет staging area, а из-за этого со всеми остальными каждодневными фичами работать крайне неудобно, например, с ребейзом. И это без учёта прикрепления остальных фич в hg через задницу - т.е. через неконсистентую систему плагинов которые ещё нужно включать руками.
Это вопрос привычки. Ребейзить через MQ не менее удобно.
> Это вопрос привычки. Ребейзить через MQ не менее удобно.им некогда, смузи-не-ждет! А чтобы разобраться с mq, надо все же потратить немного времени.
(так ли уж "удобно" иметь вечный бардак в своей копии репо, из-за которого нужна такая работа - ну хз... У линуксеров вот только так и принято.)
> смузи-не-ждет!А что, теперь git - это хипстерство, а hg - стабильный ынтерпрайз? Буду знать.
Юзеров SVN, кажется, совсем перестали брать в расчет. Символично, особенно в контексте новости.
>> смузи-не-ждет!
> А что, теперь git - это хипстерство, а hg - стабильный ынтерпрайз?оба хуже. Но если выводы делаются на основе того что в гите осилен только rebase, а в hg, ну надо же, либо ты разбираешься с mq, либо все твои ляпы становятся общественным достоянием, то, увы, напрашиваются выводы о сделавшем.
> Юзеров SVN, кажется, совсем перестали брать в расчет. Символично, особенно в контексте
> новости.а чего новость? Ну движется оно вроде в правильном направлении, со скоростью материкового дрейфа. shelve давно хотелось, остальное лично мне без надобности, хотя тому кто мержит большие изменения, наверное, действительно станет меньше геморроя. Проверять как это все работает, будем через годик, потому что нужен апгрейд репо, а этого в энтерпрайзах не любят.
Это не вопрос привычки, здесь имеется большая разница в качестве результата.Во-первых, речь шла про stage area, это хрень с помощью которой можно легко и удобно набирать изменения в коммит. Фича нужна как при формировании обычных коммитов, так и для редактирования истории ребейзом. В hg ничего похожего по удобству нет даже с учётом всех дополнений.
Во-вторых, mq это врезка сбоку к VCS для задействования которой в качестве ребейза нужно делать больше телодвижений. Кроме мудотни с наполнением mq имеет ограниченную поддержку автоматического разрешения конфликтов по сравнению с полноценным ребейзом.
Спасибо, я умею пользоваться git и в курсе, что такое staging area. :)Для формирования коммитов мне в hg обычно хватает и обычного commit --amend (я и в гите часто так делаю).
Что касается ребейза, hg rebase --mq нормально работает уже довольно давно. Но согласен, что в гите несколько удобнее с этим.
Впрочем, если при ребейзе много конфликтов, это в целом не очень нормальная ситуация вне зависимости от VCS. Если я вынужден держать долгоиграющую фичеветку, я делаю ребейз на мастер как минимум раз в пару дней.
"в разработке, где нужен именно git, потому что все другое ниасилено гордыми разработчиками"
- поправил, не благодари.фичи, включаемые плагинами, потому и фичи, чтобы перед включением лишний раз остановиться и подумать - оно действительно надо, или я тащу в другую систему плохие привычки из гита (например, привычку подменять историю).
Единственно, что есть знакового в hg - это tourtoise hg workbench. Поэтому нубы и вiндузятники так благоволят hg, особенно после svn.Архитектура гит лучше ртути. Даже не касаясь плагинов (mq из них последняя проблема, на самом деле), это в первую очередь то, что имена веток входят в ченджсет, что делает аналог фичи git remote неюзабельным. Ну и сами ветки... буэ. Предлагаемые же bookmark кривы и не фундаментальны, запросто теряются.
> Единственно, что есть знакового в hg - это tourtoise hg workbench.а че в ней знакового? Я как раз svn'овской-то версией пользуюсь, за неимением чего лучшего под винду, но как-то глобальных прелестей по сравнению с штатной в юниксах (где помимо нее есть fileutils, разумеется, а "десткоп интеграция" нахрен не упала, нету у меня десктопа) не осознал.
графический diff ? Он чем-то лучше того что в kde?> это в первую очередь то, что имена веток входят в ченджсет
мне вот очень нравится, что таки входят, и их невозможно подделывать, как и всю остальную историю. Есть ветка - значит, навсегда. И ее всегда можно проследить от появления и до закрытия. В отличие от git'а, где это просто метка одной из голов. Ну, если по дурости создал лишнюю и успел кому-то передать - живешь теперь с ней, ничего страшного.
Для ненавсегда есть букмарки. Что вы в них ниасиливаете - непонятно, поскольку это именно аналоги гитовских "веток".> что делает аналог фичи git remote неюзабельным.
а тут я чего не знаю про git remote? Для меня это всегда была неудобная замена добавления чужих репо в hgrc, для неосиляторов vi, а тут, внезапно, какая-то метафизическая сущность в ней заложена?
> Единственно, что есть знакового в hg - это tourtoise hg workbench
> нубы и вiндузятники:-)
Ты слишком глупый чтобы мне что-то править.> фичи, включаемые плагинами, потому и фичи, чтобы перед включением лишний раз остановиться и подумать - оно действительно надо, или я тащу в другую систему плохие привычки из гита...
Для овощей напомню что в hg примерно всё за пределами функциональности сvs сделано плагинами. До недавнего времени даже подсветка цветами была плагином и её нужно было включать руками. Сделано так только по одной единственной причине: разработчики ртути не умеют дизайнить приложения.
Теперь модульность - это признак плохого дизайна? :)
> Теперь модульность - это признак плохого дизайна? :)You've got it!
> или я тащу в другую систему плохие привычки из гита (например, привычку подменять историю)Привычка подменять _локальную_ историю фичевктеи - хороша и правильна.
К сожалению, абсолютно все VCS делают использование workflow вида git-flow-rebase сложнее, чем оно должно бы быть.
> Привычка подменять _локальную_ историю фичевктеи - хороша и правильна.а зачем тогда локальная история тебе вообще нужна? (ты ж rebase делаешь в _своей_ копии) Просто как замена undelete ?
В случае гита настоящая история остается в безымянной ветке, которая бестолку занимает место у тебя на диске и которую ты не найдешь никогда (да и толку от нее теперь, после rebase и продолженной работы поверх него?) А вот mq штука более злая, поскольку после игрищ с qpop/qdelete история по-настоящему изменена, и в ней натурально больше нет того, что ты удалил. (если хочется "как в git" - мертвые "невидимые" ветки - для этого есть evolve. Кстати, и массовые конфликты после себя оно тоже "как в git" прибирает [правда, криво])
Я не совсем то имел ввиду.
После того, как я squash-нул в один или пачку коммитов, нафиг не нужна.
> Новая система также научилась определять операции перемещения и переименования в истории репозиторияНеужели теперь можно не делать svn mv и это ископаемое само догадается о переименовании методом rm + add?
> это ископаемоеЭто не ископаемое. Ископаемое™ — не это.
по существу будет замечание?
> Неужели теперь можно не делать svn mv и это ископаемое само догадаетсянет, наоборот, насколько я понимаю - mv перестало быть безмозглым rm+add.
> о переименовании методом rm + add?
а зачем ты это делаешь?
Пожелаем gcc и llvm наконец пользоваться нормальным инструментом (git).
Уж лучше Mercurial. Там хоть справка "из коробки" на русском языке и нет ломки истории в порядке вещей.
Шок, сенсация, изя не осилил английский!
Ему лицензия запрещает осилить git, поэтому жрёт кактус.
Добавьте нормальную ссылку к новости: git://git.apache.org/subversion.git
Ну, артист!
> Добавьте нормальную ссылку к новости:Вообще-то нормальной была бы https://subversion.apache.org/docs/release-notes/1.10.html