После 6 месяцев разработки организация Apache Software Foundation опубликовала (https://svn.haxx.se/dev/archive-2019-04/0028.shtml) релиз системы управления версиями Subversion 1.12.0 (http://subversion.apache.org). Несмотря на развитие децентрализованных систем, Subversion продолжает пользоваться популярностью в коммерческих компаниях и проектах, использующих централизованный подход к управлению версиями и конфигурацией программных систем. Из использующих Subversion открытых проектов можно отметить: проекты Apache, FreeBSD, Free Pascal, OpenSCADA, GCC и LLVM. Выпуск Subversion 1.12 отнесён к обычным выпускам, следующим LTS-релизом станет версия Subversion 1.14, которую планируют выпустить в апреле 2020 года и поддерживать до 2024 года.
Ключевые улучшения (https://subversion.apache.org/docs/release-notes/1.12.html) Subversion 1.12:- Расширены возможности интерактивного интерфейса для разрешения конфликтов, в который добавлена поддержка обработки ситуаций с перемещением элементов в другие каталоги, а также улучшен разбор случаев появления в рабочей копии репозитория не охваченных системой версионирования файлов и каталогов;
- В сервере обеспечено игнорирование определений пустых групп в правилах авторизации и вывод предупреждения при их наличии в момент запуска команды svnauthz;- На стороне клиента в Unix-подобных системах на уровне компиляции отключена по умолчанию поддержка хранения паролей на диске в открытом виде. Пользователям рекомендовано использовать для хранения паролей системы, подобные GNOME Keyring, Kwallet или GPG-Agent;
- Улучшено поведение операций копирования в исходном репозитории и рабочей копии - существующие родительские каталоги и файлы с ревизиями теперь обрабатываются корректно.
- Улучшен вывод команды "svn list": длинные имена авторов теперь не обрезаются, добавлена опция "--human-readable" (-H) для вывода размеров в читаемом виде (байты, килобайты, магабайты и т.п.);
- В команду "svn info" добавлен показ размера файлов в репозитории;
- В команде "svn cleanup" после подтверждения операций удаления игнорируемых или не охваченных версионированием элементов, теперь удаляются и каталоги с флагом защиты от записи;- В экспериментальных командах "svn x-shelve/x-unshelve/x-shelves"
повышена надёжность обработки различных типов изменений. Команды из набора "shelve" позволяют отдельно отложить незавершенные изменения в рабочей копии, чтобы срочно поработать над чем-то другим, а затем вернуть недоделанные изменения в рабочую копию, не прибегая к таким ухищрениям как сохранение патча через "svn diff" с последующим его восстановлением через "svn patch";- Повышена надёжность экспериментальной возможности сохранения слепков состояния коммитов ("commit checkpointing"), позволяющая сохранить снапшот изменений, еще не зафиксированных коммитом, и позднее восстановить в рабочей копии любую из сохранённых версий изменений (например, чтобы откатить состояние рабочей копии в случае ошибочного обновления);
URL: https://svn.haxx.se/dev/archive-2019-04/0028.shtml
Новость: https://www.opennet.me/opennews/art.shtml?num=50578
Интересно, чем разработчиков компиляторов не устраивает git?
> Интересно, чем разработчиков компиляторов не устраивает git?Оно "не лэзет".
"" There's a malformation that has turned up in the repo that may sink the conversion entirely. ""
--2018-07-11 https://gcc.gnu.org/ml/gcc/2018-07/msg00176.html
И настоящих буйных мало.Дедушка Эрик точил ножи, точил,...
"" I’m still trying to get GCC over to git and am severely hampered by test cycles that take a minimum of nine hours or so. ""
--30.04.2018 http://esr.ibiblio.org/?p=7959...потом точил топоры,...
""I do have an audacious goal for the next release, which may well be 4.0.We (I and a couple of my closest collaborators) are going to try to move the reposurgeon code to Go.""
----2018-07-11 https://gcc.gnu.org/ml/gcc/2018-07/msg00176.html...потом ему купили Большой Ящик, ...
--2014-12-07 http://esr.ibiblio.org/?p=6562...или ящик купили до, а после - купили памяти?,....
--2018-07-09 https://www.phoronix.com/scan.php?page=news_item&px=GCC-Git-......потом он перешёл с питона на Гоу, ...
--2018-12-18 https://www.phoronix.com/scan.php?page=news_item&px=GCC-Repo......почти уже перешёл, ...
...вот-вот, уже скоро!, ....
...и пообещал сделать 4,0 reposurdeon-а, ...
Но нет, ...
...пока нет. Да.
Для разработки можно слить ветки и перейти без истории, а для копирайтной археологии достаточно отдельного репозитория.
> Для разработки можно слить ветки и перейти без истории, а для копирайтной
> археологии достаточно отдельного репозитория.Когда _надо_, оно, конечно, да. Вон, Л.Т. надо было, он с 2.6.12 начАл, а "всю историю" на потом оставил.
С gcc нюанс -- оно им не надо, а ESR пытается сделать из "не надо и не переходим" => "нам не надо, но вот же оно есть -- может быть, и переходим". Или пытался...
А смысл тогда на git переходить? Сначала на каждом углу визжали про его преимущество, а потом те же люди ветки запретили плодить. А 2-3 ветки я и на svn смогу спокойно содержать.
> А смысл тогда на git переходить? Сначала на каждом углу визжали про
> его преимущество, а потом те же люди ветки запретили плодить. А
> 2-3 ветки я и на svn смогу спокойно содержать.Ты не понял или сделал вид?
Там не было ничего ни про ветки, ни про запрет оных.
Прекрати визг про "я svn могу покойно".
Расскажи подробнее о своей проблеме!1---Можете не п(ри|ере)ходить, вычёркиваю.
>> А смысл тогда на git переходить? Сначала на каждом углу визжали про
> Там не было ничего ни про ветки, ни про запрет оных.А, было-таки.
"слить ветки и перейти без истории".
Это таки не то, чего ты испугался.
Не бойся, маленький! Там написано "можно слить и перейти", а не...
"должен немедленно всё бросить и <чего ты там себе придумал-то?>".Ну-ну, не визж ^W плакай1
В психушку интернет провели? Учись писать внятно, читать невозможно же.
Ты читаешь, что пишет Andrey Mitrofanov? Ты из какой палаты?
> Ты читаешь, что пишет Andrey Mitrofanov? Ты из какой палаты?Пральна, ребяты, не обостряйтесь. Просто минусуйте не глядя. Порадуйте главрача привесами и удоями.
все просто - команды svn набираешь на автомате.Я вот уже два года в основных проектах на git, и все равно руки помнят svn )))))
> Интересно, чем разработчиков компиляторов не устраивает git?у меня есть БОЛЬШОЙ проект, который состоит из нескольких слабозависимых частей которые всёж должны быть "общей единой версии"
в свн я могу отбранчевать ветку /весь_мегапроект/кусочек_для_устройств_а/бекэнд/ и выкачать только её, а потом вмержить обратно на то же место
или в другое, например у нашего подрядчика тупые сотрудники, которые создали репу впихнув туда весь путь /srv/svn/projectname/trunk/кусочек_для_устройств_а/, более того им не предоставлялся для доработок код кусочек_для_устройств_б, и в корневом репе у нас теперь есть ветка /весь_мегапроект/подрядчик_а/кусочек_для_устройств_а/ (куда скриптом всасываются версии из репозитория подрядчика, другой физсервер где-то там за тридевятьвпн) из которой делаются мержи в /весь_мегапроект/кусочек_для_устройств_а/как в git мне это всё организовать?
> у нашего подрядчика тупые сотрудники
> как в git мне это всё организовать?Попросить объяснить тупым сотрудникам подрядчика как делать git mv и git rm?
git mv srv/svn/whatever/кусочек-чего-то-там ./
git rm -r srv
git commit -a -m 'Мы больше не тупые'
А если там сотрудники действительно тупые, то https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging
По-моему, чистой воды то, что нужно.
однажды мосью откроет для себя gitFS. я конечно хз, может репозиторий больше, чем у майков виндовый - тогда всё печально, да
> как в git мне это всё организовать?man git-submodule
Для не осиливших индусов — repo.
>> как в git мне это всё организовать?
> man git-submodule
> Для не осиливших индусов — repo.А для фбсд-ешников -- GNU Autoconf. Ура.
Кто этим вообще пользуеться в 2018?
Привет из будущего)
> Из использующих Subversion открытых проектов можно отметить: проекты Apache, FreeBSD, Free Pascal, OpenSCADA, GCC и LLVMЭти даже в 2019 еще пользуются
>> и LLVMОни уже перешли на git:
> Getting Started Quickly (A Summary)
>
> ...
>
> Checkout LLVM (including related subprojects like Clang):
>
> git clone https://github.com/llvm/llvm-project.gitДоступ по SVN пока остаётся в целях совместимости:
> Checkout via SVN (*deprecated*)
>
> Until we have fully migrated to Git, you may also get a fresh copy of the code from the official Subversion repository.Источник: https://llvm.org/docs/GettingStarted.html
А также новость: "Проект LLVM ввёл в строй официальное Git-зеркало в ходе миграции с SVN" (15.01.2019) https://www.opennet.me/opennews/art.shtml?num=49951
> На стороне клиента в Unix-подобных системах на уровне
> компиляции отключена по умолчанию поддержка хранения паролей на
> диске в открытом виде.fuck :-( опять за нас позаботились о нашей безопастносте.
Что это использовалось для автоматических скриптов деплоя - им пофиг.Что этот самый пароль, надежнейше хранимый в kwallet и других удобных для потери всего разом хренилищах, передается открытым текстом и открытым же текстом лежит в конфигах сервера - их не побеспокоило вот ни разу - это ж надо протокол менять, и криптографию учить, это не для нынешнего разработчика.
> Что этот самый пароль, надежнейше хранимый в kwallet и других удобных для потери всего разом хренилищах, передается открытым текстом и открытым же текстом лежит в конфигах сервера - их не побеспокоило вот ни разу - это ж надо протокол менять, и криптографию учить, это не для нынешнего разработчика.Ты используешь svn без ssh? Серьёзно?
А разработчика на всё не хватит. Он и так достаточно активно имитирует бурную и никомк не нужную деятельность.
> Ты используешь svn без ssh? Серьёзно?серьезно. svn+ssh - уродливейший костыль, практически бесполезный и поломанный в ста местах (попробуй-ка ограничить область видимости для юзера и потом от него запросить svn log). Кое-как можно пользоваться svn+https, этот костыль работает - но он настолько отвратителен по конструктиву, что там где можно себе позволить какие-то пароли - лучше тоже без этой прослойки.
(то ли вот дело git - вообще ничего не умеет без костылей. Кто добавлял ssh-ключи в gogs, тот поймет.)
> А разработчика на всё не хватит.
к сожалению, на очередную диверсию, как видишь, вполне хватило, и вряд ли эта - последняя.
И в следующем релизе что б-жественной бубунточки, что rhel - придется подменять пакет, потому что "промышленность немедленно перейдет на новый стандарт".
> На стороне клиента в Unix-подобных системах на уровне компиляции отключена по умолчанию поддержка хранения паролей на диске в открытом виде. Пользователям рекомендовано использовать для хранения паролей системы, подобные GNOME Keyring, Kwallet или GPG-Agent;И эти туда же?
Десяток лет старых программистов переводили на svn, долго они плювались.
Теперь вздумаете перевести их на git?Ахаха, неееет.
Есть опыт работы с 60-и летним разработчиком.
угу - мне вот вроде еще и не 60, но вспомнить, нахрена же был нужен svn при рабочем cvs я как-то не особенно и могу (ну ок, были некоторые сложности с readonly-доступом, поскольку оно зачем-то ведет лог чекаутов). Этот, как его, эклер? А, не - склероз!зато истории с восстановлением рухнувшего репо после отказа питания - я помню отлично, ага.
Потому что они повторялись с удручающей регулярностью.Попробуйте-ка добейтесь повреждения репо у cvs.
git в том виде, как его использует нынче большинство - нафиг не нужен, и, в любом виде - чудовищно неудобен.
Поскольку решает личные сексуальные проблемы Линуса, который vcs пользоваться как двадцать лет назад не умел, так и по сей день не научился.А на самом деле людям нужно веб-чятик и браузером клик-клик по дереву исходников. Для svn такое даже в принципе и есть, но какое-то немодное, немолодежное. Для hg - уже совсем нету. Перфорса дорого, начальнеге не оплатют.
>нахрена же был нужен svn при рабочем cvs я как-то не особенно и могОдин атомарный коммит чего стоит. Да и проблем с безопасностью было вагон и маленькая тележка - приходилось всех в unix пользователей пихать и т.д. и т.п.
>>нахрена же был нужен svn при рабочем cvs я как-то не особенно и мог
> Один атомарный коммит чего стоит.Репо _lock_ [или кактамего], вы хотели сказать?
>нахрена же был нужен svn при рабочем cvsCVS - no integrity test
>Попробуйте-ка добейтесь повреждения репо у cvs.
не я, HDD дохнущий пробовал и успешно сломал, но CVS даже не пикнул...
> Для hg - уже совсем нету.Bitbucket же.
> но вспомнить, нахрена же был нужен svn при рабочем cvs я как-то не особенно и могув CVS версионность по файлу, в SVN - по репозиторию. Пожалуй самое заметное отличие.
http://svnbook.red-bean.com/en/1.7/svn.forcvs.revnums.htmlВ CVS впрочем есть commit id, но не во всех реализациях поддерживается.
https://stackoverflow.com/questions/14863724/how-to-use-the-...
А нехрен было переводить на svn. Промучались бы до сих пор с cvs, глядишь, и на git сползли бы без проблем.
ну у меня есть парочка, которыми раз в пол-года пользуюсь - я, конечно, давно не смотрел что там с серверной стороны, но скачать исходник/полазать по дереву/поразбираться в конкретном комите - вполне себе без страданий могу.Ну, конечно, в cvsweb нет чятика, но там уже давно не с кем поговорить все равно.
У нас 50 лет "дедок" сам всех на git в своё время переводил.
пипец, 50 это что, уже дедок ?
60-и летнего надо отправлять на пенсию. Я бы и 50-и летних тоже отправлял. Всё равно дешевле будет. Жалко, государство до сих пор не понимает этого.
Может лучше тебя отправим? И не на пенсию, а сразу в биореактор
Тогда работай и не ной тут про проблемы 60-летних.
>Я бы и 50-и летних тоже
> отправлял. Всё равно дешевле будет. Жалко, государство до сих пор не
> понимает этого.дадад! голосую за этого Анонима в .... не знаю куда.
не хочу работать, хочу на пенсию поскорее. и видимо, зря. >?<
> не хочу работать, хочу на пенсию поскорее. и видимо, зря. >?<конечно зря - на пенсию в 45 уйдет тот росгвардеец, который ловко п-л тебя дубиной, да. Причем деньги на выплату ему этой пенсии - отожмут из твоей зарплаты.
Да и вообще надо объявить basic income, и пускай работают только те, кому приспичило поработать.
Я бы с радостью занимался своим "приспичило поработать", но добывание денег отнимает много сил и времени.
Вот из-за таких и проблемы потом. Считаю, их надо вовремя выявлять и исключать из трудового процесса. На этот случай могли бы безусловные доход придумать, как вариант. А то сейчас уходит больше средств на устранение их косяков.
"выявлять", [cenzored].Кадровики заставляют врать про "мне интересно у вас работать не ради денег".
У тебя бинарная логика что ли? Киллером можешь поработать, если только деньги интересуют?
Меня много чего интересует, но при чём тут работа? Странное стремление кончать под клиентом. На этой планете сложно без денег, вот и приходится зарабатывать.
Не знаю, что ты за "стремление кончать под клиентом" тут приводишь. В общем трудно вести разговор, когда у тебя в голове кроме меня ещё пара десятков собеседников.
Ты забыл самое главное - эти старпёры ещё и смузи отказываются пить, категорически. И не парят...
да ладно, подставляй тазик - выпью.
тазик - в смысле, чтоб было куда блевануть сразу после ;-)А это у меня - ингалятор, от...сь! Главное, не забывать выкинуть, когда летишь через арабские страны.
запомни что сказал, не успеешь оглянуться как сам окажешься на их месте...
60-летние разные бывают. Есть такие, которые сами первыми всё осваивают. А если человек закостенел, независимо от возраста — гнать такого в шею.
Ну гнать, не гнать, но вопрос надо решать. Автоматизация убила множество рабочих мест. В результате имеем то, что имеем. На 20-30 человек всего 1 "тащит". Остальные в лучшем случае не мешаются под ногами.
расскажите подробнее, чье рабочее место убила замена cvs на git ?И какую именно деятельность она лично вам "автоматизировала" ?
Рабочее место заплесневелого ретрограда, который своим ворчаньем мешал молодому, энергичному, амбициозному и продвинутому тимлиду сломать всё, что ещё оставалось работающего.
> Есть опыт работы с 60-и летним разработчиком.Ты забыл свой возраст указать.
А у меня есть опыт работы и с разработчиками за 50, и с молодыми студентами.И, прикинь, от возраста вообще ничего не зависит. Кто-то и в предпенсионном возрасте легко осваивает новое, а кто-то и в 25 лет закостенел уже.
в svn можно создавать пустые каталоги, насколько я помню :)
а в гите нельзя??? О_о
Таки да. Только с костылями.
> а в гите нельзя??? О_оНе-а.
Или в нёй другая директория (и в ней -- далее по индукции).
Или файл-"placeholder" комитить.Вот! Видишь! Какая хорошая, интересная система -- а ты не в зуб ногой.
Переходи быстрее.
> Или в нёй другая директория (и в ней -- далее по индукции).
> Или файл-"placeholder" комитить.Есть ещё вариант: mkdir или аналог в "нужном месте" скриптов сборки...
...но это не совсем "в vcs". Кажется.
А какой юзкейс? Сколько лет с гитом работаю, и ни разу такой потребности не возникало.
initial directory structure? Почти всегда первый коммит в svn.
То есть единственная причина — чтобы было как в svn?
Делали, потому что удобно. Никто же не виноват, что ты ничего кроме гита не видел.
Кто сказал, что не видел? И с svn работал, и с cvs немножко страдал. Но удобства пустых каталогов не понимаю.
svn тут не при чём. В git'е тоже первый коммит очень часто содержит в себе всякую мелочовку, типа readme, .gitignore, src/, assets/ и проч. И среди них могут быть пустые директории.Правда я не вижу в этом большой проблемы: никто не мешает класть в каждую директорию файлик .keep
Костыль, конечно, но вполне пристойный, и более того довольно широкоиспользуемый и вне git.
Серьёзно? А директории под ./runtime/ какой-нибудь, ./cache/ какой-нибудь не нужны?
Коммитить не исходники - кю. Лучше прописать их создание в какой-нибудь makefile.
Нет, не нужны. Репозиторий для исходного кода, а не для помойки.
а вот и типичный адепт нового-модного пожаловал. s/репозиторий/git/gи так и запишем - в гите без использования костылей можно хранить только какой-то волшебный "исходный код", в отличие от нормальных vcs, где хранятся состояния дерева проекта.
Который, внезапно, вообще может быть не "исходным кодом".
Ну а чего вы хотели от поделки Линуса, который и исходники-то хранил в linux-1.2.11, linux-1.2.12 ... , "патчи присылайте мэйлом, не забыв порезать по две строчки, а то их читать неудобно".
Почитай про vcs в Гугле, это эпический костыль. Они используют vcs не только вместо rsync, но и вместо пакетного менеджера. И сгенерированных файлов туда столько навалили, что на ноутбучные диски не влезает.
> в отличие от нормальных vcs, где хранятся состояния дерева проекта.
> Который, внезапно, вообще может быть не "исходным кодом".И что же вы подразумеваете под состоянием? .o-файлы и мусор имени maven/gradle, который иногда быстрее локально регенерировать из исходников, чем скачать из репозитория даже без истории, и который нужен только два раза в жизни? Я уж молчу об svn, который не хранит mtime, и о разработчиках, которые забывают закоммитить промежуточные артефакты сборки. А сколько боли доставляет деление изменений на несколько коммитов и промежуточные коммиты, которые вообще не должны порождать .o-файлов, ммм…
Или вы rpm-пакетах и готовых к использованию ELF-бинарях, положенные в VCS от безысходности, потому что кто-то допустил вырастание невоспроизводимых серверов с патченым непоймичем и ~mamkin.devops в LD_LIBRARY_PATH? (True, блин, story, из-за таких серверов одно время приходилось тратить место на бекапы svn-реп с невероятными горами бинарного мусора в истории — даже после радостного выведения их из эксплуатации.)
> svn, который не хранит mtimeМожно подумать, какая-то другая VCS хранит.
>> svn, который не хранит mtime
> Можно подумать, какая-то другая VCS хранит.Дык пафоса у поха столько, что может сложиться впечатление, что svn и хранит. Но нет.
По крайней мере есть:[miscellany]
use-commit-times = yesкоторое может как-то помочь в этом.
> А какой юзкейс? Сколько лет с гитом работаю, и ни разу такой
> потребности не возникало." Каша-то всегда была тёплая. "
commit 012fdeadc24066d99f55
Author: Andrey Mitrofanov <
Date: Wed Jul 23 18:34:47 2014 +0400Added an empty dir placeholder, for java gw build.
+ No mkdir will be needed before make of git-archive-d source.
>WONTFIX in upstream, ZBX-7320.diff --git a/src/zabbix_java/bin/.gitignore b/src/zabbix_java/bin/.gitignore
new file mode 100644
index 00000000..7988d6f8
--- /dev/null
+++ b/src/zabbix_java/bin/.gitignore
@@ -0,0 +1,2 @@
+#This file is an empty dir placeholder. For git that is.
+zabbix-java-gateway-*.jar
он научился с socks проекси работать?
> он научился с socks проекси работать?Тяжело на винде-то? Без soxify-то. Должен страдать.
Кто может назвать и популярно объяснить десять причин использовать SVN вместо Mercurial?
Тут гитосрач, не мешайте со своим меркуриалом.