It's a wish that the new advanced svn behaves in a sensible way when it makes HTTP requests (similarly to browsers which do determine a suitable "version" of HTTP for each server): new svn could fallback to the old way to do HTTP requests if the server doesn't support the new one https://lists.altlinux.org/pipermail/devel/2015-December/200479.html : Кому-то ещё может пригодиться, если брать исходники по svn: subversion-1.7.8-alt2.1 (который был когда-то в p7) и тот, который в p6, умел: svn co http://svn.botik.ru/refal/to-imperative/trunk /usr/src/refal-trun Новый из Sisyphus (и p7) не может: svn: E175002: Unexpected HTTP status 400 'Bad Request' on '/refal/to-imperative/trunk' Преодолеть это можно так ( http://stackoverflow.com/a/22713369/94687 ): svn --config-option servers:global:http-chunked-requests=no co http://svn.botik.ru/refal/to-imperative/trunk /usr/src/refal-trunk
Предлагаешь опцию конфигурирования по умолчанию включить?
(In reply to comment #1) > Предлагаешь опцию конфигурирования по умолчанию включить? Это в первую очередь претензия к апстриму, что у них нет такого fallback. Что лучше делать в условиях, когда мы дописывать такую возможность не будем, не очень ясно: ожидать, что все пользователи svn в Sisyphus должны обучиться, как обходить эту новую "поломку", или спрятать это от них в конфигурации, сделав HTTP-запросы от svn не такими продвинутыми, как он умеет в последних версиях... Мейнтейнер пакета мог бы быть в курсе планов апстрима на этот счёт и принять подходящее решение. Лучше узнать мнение тех, кого это сильнее касается, чем меня.
(In reply to comment #1) > Предлагаешь опцию конфигурирования по умолчанию включить? Предлагаю эти опции в p7 включить. > Причём в p7 это случается вдруг: я ставил себе систему из p7 некоторое время назад, у меня работало. А если обновить subversion из нынешнего p7, уже не работает. Это же нарушает ожидания от p7, что то, что работало, не будет ломаться. -- https://lists.altlinux.org/pipermail/devel/2015-December/200520.html
