The OpenNET Project / Index page

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

Релиз системы управления версиями Apache Subversion 1.10.0

15.04.2018 18:34

После почти трёх лет разработки состоялся релиз новой ветки системы управления версиями Subversion 1.10.0. Несмотря на развитие децентрализованных систем, Subversion продолжает пользоваться популярностью в коммерческих компаниях и проектах, использующих централизованный подход к управлению версиями и конфигурацией программных систем. Из использующих Subversion открытых проектов можно отметить: проекты Apache, FreeBSD, Free Pascal, OpenSCADA, GCC и LLVM.

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

  • Представлена новая реализация механизма авторизации на основе путей, дающего возможность определить правила доступа к отдельным каталогам в репозитории. Помимо ранее предлагаемых правил "[repos:/path]" и "[/path]", которые допускают только точные совпадения путей, новая реализация позволяет использовать два новых формата "[:glob:repos:/path]" и "[:glob:/path]", допускающих использование масок. Для создания масок предлагается использовать классические маски вида *foo*.bar, а также конструкции "/*/" для сопоставления с одним сегментом пути и "/**/" для сопоставления с произвольным числом сегментов пути;
  • Полностью переработана интерактивная система разрешения конфликтов, которая ищет в истории репозитория структурные изменения (операции добавления, удаления, копирования и перемещения), которые конфликтуют с локальными изменениями в рабочей копии и приводят к образованию конфликтов. В новой реализации дерево конфликтов снабжено детальными сведениями, которые раньше приходилось искать вручную, в том числе указаны номера ревизий и имена разработчиков конфликтующих изменений. Новая система также научилась определять операции перемещения и переименования в истории репозитория и учитывать их при изменении локальной рабочей копии, что сделало процесс слияния между ветками максимально прозрачным, в случае если в одной или в обеих ветках выполнялись операции переименования файлов или каталогов. Конфликты которые имеют однозначное решение теперь по возможности разрешаются автоматичести, без запроса пользователя (например, когда файл перемещён в другое место репозитория);
  • Добавлена поддержка механизма сжатия LZ4, в качестве альтернативы ранее предлагавшейся системе zlib. LZ4 существенно превосходит zlib по скорости сжатия и распаковки, сохраняя при этом приемлемую степень сжатия. Как результат, переход на LZ4 позволяет существенно увеличить производительность операций чтения и записи, особенно если репозиторий включает большие файлы. Поддержка LZ4 включена по умолчанию для сжатия данных в репозитории (версия формата хранилища 8), а также применяется для сжатия трафика при доступе к внешнему репозиторию по "http://" и "svn://". Для обновления до новой версии формата хранилища можно использовать команду "svnadmin upgrade";
  • Добавлены экспериментальные команды "svn shelve/unshelve/shelves", позволяющие отдельно отложить незавершенные изменения в рабочей копии, чтобы срочно поработать над чем-то другим, а затем вернуть недоделанные изменения в рабочую копию. Поведение предлагаемой возможности похоже на сохранение патча, созданного через "svn diff", с последующим его восстановлением через "svn patch";


  1. Главная ссылка к новости (https://svn.haxx.se/dev/archiv...)
  2. OpenNews: Увидела свет система управления версиями Apache Subversion 1.9.0
  3. OpenNews: Уязвимость в Git, Subversion и Mercurial, допускающая подстановку команд через URL ssh://
  4. OpenNews: Увидела свет система управления версиями Subversion 1.8.0
  5. OpenNews: Релиз системы управления версиями Subversion 1.7.0
  6. OpenNews: Выпуск распределенной системы управления исходными текстами Git 2.16.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/48444-subversion
Ключевые слова: subversion, svn
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (51) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 19:49, 15/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Это типа git ?
     
     
  • 2.2, Анонидзе (?), 19:50, 15/04/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да, только централизованный.
     
  • 2.3, Аноним (-), 19:50, 15/04/2018 [^] [^^] [^^^] [ответить]  
  • +14 +/
    Это типа CVS.
     

  • 1.6, Аноним (-), 20:02, 15/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    > Из использующих Subversion открытых проектов можно отметить:  ... GCC

    вот: https://gcc.gnu.org/git/?p=gcc.git;a=summary

     
     
  • 2.10, Андрей (??), 20:31, 15/04/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Но это всего лишь зеркало:
    description Mirror of all GCC SVN branches and tags
     

  • 1.7, Аноним (-), 20:16, 15/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Время от времени эта ерунда всплывает на работе, а все уже забыли, как ею пользоваться. Ржом и гуглим.
     
     
  • 2.8, klalafuda (?), 20:23, 15/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Что там гуглить то? Практически также как и CVS.
     
  • 2.9, KonstantinB (ok), 20:30, 15/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пользоваться надо вот так:
    https://git-scm.com/docs/git-svn
     
  • 2.44, Вареник (?), 18:26, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Она как раз простейшая в использовании. В дереве разобраться и все. В нем и теги, и все сразу наглядно.
     

  • 1.11, Gemorroj (ok), 20:46, 15/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    хорошая vcs, жаль не в трендах
     
     
  • 2.13, пох (?), 21:32, 15/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    боюсь спросить, как же тогда выглядят плохие?

    http://www.robgonda.com/blog/index.cfm/2007/10/19/SVN-PROPFIND-request-failed
    o-Such-Revision

    (это чуваку повезло, на самом деле нет никаких вариантов выяснить, какая версия на самом деле последняя, можно только угадать, на какую откатываться, но никак не узнать, не потерял ли ты данные)

    http://stackoverflow.com/questions/13031544/empty-or-non-existent-db-txn-curr
    -in-a-subversion-repository
    (ну тут просто, "any 64value will work", правда, пока ты с этим разбираешься, репо не работает)
    и да, угадайте, почему я знаю о существовании этих статей.

    про неработающий svn log в частично permissionless/частично нет (в public части репо) я уж молчу, право, какая мелочь.
    (да, я понимаю, что модные-современные и такого-то не умеют)

     
     
  • 3.16, Gemorroj (ok), 21:51, 15/04/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    это какие-то кастомные проблемы (первая ссылка битая, вторая давно пофикшена, судя по твоей же ссылке), за много лет работы не сталкивался.
    мне неудобства доставляет только отсутствие .svnignore. управлять игнорами на уровне хуков неудобно.
     
     
  • 4.18, vitalif (ok), 22:40, 15/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    svn:ignore вроде свойство же
     
     
  • 5.21, пох (?), 22:54, 15/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > svn:ignore вроде свойство же

    оно per-dir, и не наследуется, это уж точно вредная фича (потому что ее вообще не видно, если не знать что оно тут используется)

    можно такой же список держать в config, но он, естественно, будет твой личный, а не в репо.
    Если нужно чтобы автоприлетало каждому Васяну, вчера получившему туда доступ, пока он не накоммитил чего лишнего - не вариант.


     
  • 5.22, Gemorroj (ok), 23:24, 15/04/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    я и говорю неудобно
     
  • 4.19, пох (?), 22:44, 15/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > это какие-то кастомные проблемы

    это банальное последствие приземления сервера не на все четыре лапы (в моем случае старательно отваливалась hp 3par - "за много лет работы" я тоже не сталкивался, что san'овская хранилка вот она есть, но ее - нет. А оно, вот...)
    Удивительная структура svn'овского репо оказалась на редкость уязвимой к крэшам и практически не имеющей средств починки. А поскольку это нифига не distributed vcs - геморрой обеспечен.

    нате вам обе ссылки, защищенные от местных странных парсеров:
    https://tinyurl.com/yb568dea
    https://tinyurl.com/mqnmokr

    > мне неудобства доставляет только отсутствие .svnignore. управлять игнорами на уровне хуков
    > неудобно.

    по-моему так и наоборот, там их видно, вместе со всей остальной местной спецификой, в отличие от файла о котором все время надо отдельно помнить. Но для моих целей оно вообще очень редко нужно.
    (то есть, собственно, единственный частоиспользуемый мной ignore - * - поскольку это мой хомяк)

    А вот ситуация когда мы держали-держали развесистое дерево репо, а потом внезапно решили часть его попрятать хотя бы под svn permissions - случалась. Оно при этом как-то работает, но изрядно странно.

     
  • 3.17, Gemorroj (ok), 21:54, 15/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    не знаю как выглядят плохие, у меня опыт ограничен git/mercurial/svn. у всех есть плюсы-минусы.
     
  • 3.27, Аноним (-), 00:01, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > боюсь спросить, как же тогда выглядят плохие?

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

     
  • 3.38, Аноним (-), 12:08, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Как плохие выглядят монорепы на гите.
     
  • 2.24, all_glory_to_the_hypnotoad (ok), 23:28, 15/04/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > хорошая vcs, жаль не в трендах

    Именно как vcs subversion днище, но ничётак в качестве версионированной фс для файловой помойки - так её обычно и используют.

     
     
  • 3.25, Gemorroj (ok), 23:32, 15/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    вобщем да, но зачастую этого и достаточно.
     
     
  • 4.26, all_glory_to_the_hypnotoad (ok), 23:59, 15/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    нет, недостаточно. В разработке, т.е. где нужна именно vcs, недостаточно даже hg.
     
     
  • 5.29, KonstantinB (ok), 02:28, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А чем hg то недостаточно со всеми стандартными плагинами? Все то же, что и в гите, можно сделать.
     
     
  • 6.31, all_glory_to_the_hypnotoad (ok), 03:48, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Нет staging area, а из-за этого со всеми остальными каждодневными фичами работать крайне неудобно, например, с ребейзом. И это без учёта прикрепления остальных фич в hg через задницу - т.е. через неконсистентую систему плагинов которые ещё нужно включать руками.
     
     
  • 7.33, KonstantinB (ok), 06:36, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это вопрос привычки. Ребейзить через MQ не менее удобно.
     
     
  • 8.35, пох (?), 08:59, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    им некогда, смузи-не-ждет А чтобы разобраться с mq, надо все же потратить немно... текст свёрнут, показать
     
     
  • 9.39, Аноним (-), 12:53, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А что, теперь git - это хипстерство, а hg - стабильный ынтерпрайз Буду знать Ю... текст свёрнут, показать
     
     
  • 10.46, пох (?), 21:20, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    оба хуже Но если выводы делаются на основе того что в гите осилен только rebase... текст свёрнут, показать
     
  • 8.48, all_glory_to_the_hypnotoad (ok), 23:46, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это не вопрос привычки, здесь имеется большая разница в качестве результата Во-... текст свёрнут, показать
     
     
  • 9.50, KonstantinB (ok), 01:46, 17/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо, я умею пользоваться git и в курсе, что такое staging area Для форми... текст свёрнут, показать
     
  • 5.34, пох (?), 08:47, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    "в разработке, где нужен именно git, потому что все другое ниасилено гордыми разработчиками"
    - поправил, не благодари.

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

     
     
  • 6.40, Аноним (-), 13:03, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Единственно, что есть знакового в hg - это tourtoise hg workbench. Поэтому нубы и вiндузятники так благоволят hg, особенно после svn.

    Архитектура гит лучше ртути. Даже не касаясь плагинов (mq из них последняя проблема, на самом деле), это в первую очередь то, что имена веток входят в ченджсет, что делает аналог фичи git remote неюзабельным. Ну и сами ветки... буэ. Предлагаемые же bookmark кривы и не фундаментальны, запросто теряются.

     
     
  • 7.45, пох (?), 21:13, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Единственно, что есть знакового в hg - это tourtoise hg workbench.

    а че в ней знакового? Я как раз svn'овской-то версией пользуюсь, за неимением чего лучшего под винду, но как-то глобальных прелестей по сравнению с штатной в юниксах (где помимо нее есть fileutils, разумеется, а "десткоп интеграция" нахрен не упала, нету у меня десктопа) не осознал.
    графический diff ? Он чем-то лучше того что в kde?

    > это в первую очередь то, что имена веток входят в ченджсет

    мне вот очень нравится, что таки входят, и их невозможно подделывать, как и всю остальную историю. Есть ветка - значит, навсегда. И ее всегда можно проследить от появления и до закрытия. В отличие от git'а, где это просто метка одной из голов. Ну, если по дурости создал лишнюю и успел кому-то передать - живешь теперь с ней, ничего страшного.
    Для ненавсегда есть букмарки. Что вы в них ниасиливаете - непонятно, поскольку это именно аналоги гитовских "веток".

    > что делает аналог фичи git remote неюзабельным.

    а тут я чего не знаю про git remote? Для меня это всегда была неудобная замена добавления чужих репо в hgrc, для неосиляторов vi, а тут, внезапно, какая-то метафизическая сущность в ней заложена?

     
  • 7.52, KonstantinB (ok), 05:41, 17/04/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Единственно, что есть знакового в hg - это tourtoise hg workbench
    > нубы и вiндузятники

    :-)

     
  • 6.49, all_glory_to_the_hypnotoad (ok), 00:00, 17/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ты слишком глупый чтобы мне что-то править.

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

    Для овощей напомню что в hg примерно всё за пределами функциональности сvs сделано плагинами. До недавнего времени даже подсветка цветами была плагином и её нужно было включать руками. Сделано так только по одной единственной причине: разработчики ртути не умеют дизайнить приложения.

     
     
  • 7.51, KonstantinB (ok), 05:38, 17/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Теперь модульность - это признак плохого дизайна? :)
     
     
  • 8.55, Lennart (?), 15:21, 17/04/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    You ve got it ... текст свёрнут, показать
     
  • 6.53, KonstantinB (ok), 05:45, 17/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > или я тащу в другую систему плохие привычки из гита (например, привычку подменять историю)

    Привычка подменять _локальную_ историю фичевктеи - хороша и правильна.

    К сожалению, абсолютно все VCS делают использование workflow вида git-flow-rebase сложнее, чем оно должно бы быть.

     
     
  • 7.56, пох (?), 20:09, 17/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Привычка подменять _локальную_ историю фичевктеи - хороша и правильна.

    а зачем тогда локальная история тебе вообще нужна? (ты ж rebase делаешь в _своей_ копии) Просто как замена undelete ?
    В случае гита настоящая история остается в безымянной ветке, которая бестолку занимает место у тебя на диске и которую ты не найдешь никогда (да и толку от нее теперь, после rebase и продолженной работы поверх него?) А вот mq штука более злая, поскольку после игрищ с qpop/qdelete история по-настоящему изменена, и в ней натурально больше нет того, что ты удалил. (если хочется "как в git" - мертвые "невидимые" ветки - для этого есть evolve. Кстати, и массовые конфликты после себя оно тоже "как в git" прибирает [правда, криво])

     
     
  • 8.57, KonstantinB (ok), 04:42, 18/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я не совсем то имел ввиду После того, как я squash-нул в один или пачку коммито... текст свёрнут, показать
     

  • 1.23, all_glory_to_the_hypnotoad (ok), 23:24, 15/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Новая система также научилась определять операции перемещения и переименования в истории репозитория

    Неужели теперь можно не делать svn mv и это ископаемое само догадается о переименовании методом rm + add?

     
     
  • 2.28, Аноним (-), 00:03, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > это ископаемое

    Это не ископаемое. Ископаемое™ — не это.

     
     
  • 3.41, Аноним (-), 13:04, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    по существу будет замечание?
     
  • 2.47, пох (?), 21:22, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Неужели теперь можно не делать svn mv и это ископаемое само догадается

    нет, наоборот, насколько я понимаю - mv перестало быть безмозглым rm+add.

    > о переименовании методом rm + add?

    а зачем ты это делаешь?


     

  • 1.30, Аноним (-), 03:10, 16/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Пожелаем gcc и llvm наконец пользоваться нормальным инструментом (git).
     
     
  • 2.36, iZEN (ok), 10:46, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Уж лучше Mercurial. Там хоть справка "из коробки" на русском языке и нет ломки истории в порядке вещей.
     
     
  • 3.37, Аноним (-), 11:05, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Шок, сенсация, изя не осилил английский!
     
     
  • 4.43, Аноним (-), 15:40, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ему лицензия запрещает осилить git, поэтому жрёт кактус.
     

  • 1.32, Аноним (-), 05:01, 16/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Добавьте нормальную ссылку к новости: git://git.apache.org/subversion.git

     
     
  • 2.42, anonymous (??), 14:37, 16/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, артист!

    https://svn.apache.org/repos/asf/subversion/trunk s

     
  • 2.54, SysA (?), 11:37, 17/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Добавьте нормальную ссылку к новости:

    Вообще-то нормальной была бы https://subversion.apache.org/docs/release-notes/1.10.html

     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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