LINUX.ORG.RU

Обновление Subversion 1.7.7

 


0

2

9 октября Subversion, свободная централизованная система управления версиями, обновилась до версии 1.7.7.

Ключевые изменения на клиентской стороне:

  • устранены проблемы с применением Git патчей;
  • устранена проблема, когда при апгрейде внешние объекты (externals) из разных репозиториев имели некорректные repos_id и не содержали def_repos_relpath в строке EXTERNALS (#4016);
  • устранена проблема, когда внешние файлы (file externals) не обновлялись со старым mod_dav_svn (#4224);
  • устранена проблема дублирования строк «Index:» при 'svn diff';
  • устранена проблема взаимодействия библиотеки keyring и старых версий glib;
  • исправлена некорректная реакция на неправильное хранилище паролей (password store), указанное в конфигурационном файле;
  • устранена проблема создания рабочей копии (checkout) или экспорта (export) большого количества файлов на Windows (#4174).

Ключевые изменения на серверной стороне:

  • устранена проблема создания каталогов из WEB-интерфейса (посредством HTTP протокола) при «SVNAutoversioning on» (#4231);
  • устранено некорректное поведения svndumpfilter, когда при использовании --targets file.txt в файле file.txt (в данном примере) игнорировались пути, которые не начинались с '/' (#4234);
  • ttl для memcached установлено в 50 секунд.

>>> Полный список изменений

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 1)
Ответ на: комментарий от quest

Если SVN используется вместо GIT то это действительно ужасно.
Но у него есть свои фичи и свой способ использования, при котором он превосходит GIT.

Например публичный read-only репозиторий, в который помещаются исключительно публичные релизы (например, для соблюдения GPL) удобнее сделать на SVN.

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

German_B
()
Ответ на: комментарий от anonymous

У нас не будут париться и напишут в комментарий к коммиту «Поправили тут задним числом»

GblGbl ★★★★★
()
Ответ на: комментарий от German_B

Кому не нужно, те и не пользуются. ИМХО, svn удобно держать на централизованном сервере, а у каждого разраба на машинах - git и коммитить из него в svn

что-ж не в CVS? или в perforce прости господи?

quest ★★★★
()
Ответ на: комментарий от etwrq

ну такой же тупица как ты освоил? Что там сложного? первая сложность обычно возникает при мерджи когда он не проходит, это гуглится и дальше вполне нормально работает.

anonymous
()
Ответ на: комментарий от quest

что-ж не в CVS? или в perforce прости господи?

Потому что новость об SVN

То, что конкретно для коллективной разработки программ сама концепция централизованных систем оказалась менее удачной чем DCVS - это другой вопрос.

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

German_B
()
Ответ на: комментарий от German_B

Например публичный read-only репозиторий, в который помещаются исключительно публичные релизы (например, для соблюдения GPL) удобнее сделать на SVN.

Какая тут разница между svn и нормальными SCM?

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

Какая тут разница между svn и нормальными SCM?

anonymous
()

Простенькая задачка для любителей DCVS:

У вас есть багтрекер для вашего проекта. Нужно все коммиты-багфиксы проверять на содержание номера бага. И не давать коммитить, если номера нет.

В случае SVN это делается на коленке минут за 15...

anonymous
()
Ответ на: комментарий от anonymous

Простенькая задачка для любителей DCVS:

DVCS. А сама задачка уровня «Сара Бара-бу, стань коровой Му». Понятно, что очень трудно запретить делать коммиты, не удовлетворяющие скриптовому условию. Но легко сделать так, что эти коммиты не попадут в общий репозиторий.

tailgunner ★★★★★
()
Ответ на: комментарий от German_B

ИМХО, svn удобно держать на централизованном сервере, а у каждого разраба на машинах - git и коммитить из него в svn

git и коммитить из него в svn

А КАК ЭТО???

hobbit ★★★★★
()
Ответ на: комментарий от true_admin

мне у svn ужасно нравится одна фишка: любой каталог это репозиторий.

К великому моему сожалению - уже нет. Авторы насмотрелись на новомодные DVCS-поделия, и теперь .svn только в корне.

Я пока сижу на старых версиях...

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

А КАК ЭТО???

думаю git так умеет. И mercurial тоже, если не ошибаюсь (правда, не фонтан оно работало когда тестил). У нас svn тоже как common denominator, но народ что попало использует.

true_admin ★★★★★
()
Ответ на: комментарий от hobbit

кто-то ещё использует легковушки вместо КАМАЗов?

да прям камазы :)

true_admin ★★★★★
()
Ответ на: комментарий от hobbit

К великому моему сожалению - уже нет. Авторы насмотрелись на новомодные DVCS-поделия, и теперь .svn только в корне.

Сделать checkout можно все равно для любого поддерева, не то что в git/hg. Если не нужны сотни мегабайт тестов, то можно забрать из репозитория только то, что нужно.

Также хранить толстые бинарники и таскать все их версии в каждом клоне в dvcs не вариант.

Ну и перенос 100мб тестов из одной директории в другую раздул hg repo как раз на эти 100мб, как-то совсем убого сделан rename в hg.

kamre ★★★
()
Ответ на: комментарий от hobbit

Что, кто-то ещё использует легковушки вместо КАМАЗов? Ужас-ужас (((

не тут такое совершенно не катит))) Git просто лучше. Во всем. Это как глоток свежего воздуха!)

quest ★★★★
()
Ответ на: комментарий от anonymous

И не давать коммитить, если номера нет.
В случае SVN это делается на коленке минут за 15...

А в случае Git это вообще не надо делать. Либо все же договорится с кодерами, либо создать «грязный» репозитарий из которого главный программер будет перекоммичивать в «чистый»

quest ★★★★
()
Ответ на: комментарий от hobbit

Я пока сижу на старых версиях...

SVN просто хуже. хватит сидеть, присоединяйтесь к бегущим)

quest ★★★★
()
Ответ на: комментарий от vurdalak

Precommit hooks. Пожалуй, единственное преимущество svn, но для крупных компаний критическое. В git-е централизовано коммитить не запретишь.

anonymous
()
Ответ на: комментарий от German_B

Любую VCS любой человек с IQ>=100 освоит за 30 минут. Даже bazaar. А уж между git и svn в этом плане и вовсе разницы никакой.

Так что, не надо нанимать лиц с IQ меньше чем 100 единиц. Их вообще никуда не надо нанимать. Они даже улицы подметать как следует не способны.

anonymous
()
Ответ на: комментарий от Nanodesu

Вендой без cygwin пользуются только клинические идиоты. А, как было сказано выше, клиническим идиотам вообще любая работа противопоказана.

anonymous
()
Ответ на: комментарий от hobbit

Старые версии мержить не умеют. Вообще. Так что сиди, сиди, мож что высидишь.

anonymous
()
Ответ на: комментарий от anonymous

Create a shallow clone with a history truncated to the specified number of revisions.

И как это поможет забрать из репозитория только поддерево и работать с ним?

kamre ★★★
()
Ответ на: комментарий от anonymous

Мне сочетание pytty+cygterm нравится, в koi-то веки юзабельный эмулятор терминала под форточками.
Я вот все жду, когда появится герой, который портирует apt нативно и репозиторий будет поддерживать - чтобы через него на голый шиндовс и cygwin, и vcs, python ставить одной командой и, что самое главное - обновлять, без десятков отвратительных инсталлер.exe.

Nanodesu
()
Ответ на: комментарий от Nanodesu

Но все кто мог бы подобное провернуть в определенный момент понимают, что проще wine или виртуалочку поставить под gnu/linux.

Nanodesu
()
Ответ на: комментарий от kamre

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

anonymous
()
Ответ на: комментарий от anonymous

С поддеревом не поможет (это и не надо делать, это глупо и плохо)

Какая банальщина: если чего-то нет, то оно сразу не нужно/глупо/плохо :)

Это весьма полезная фича svn, которую никак не могут нормально сделать в git/hg. Только костыли вроде subrepos/subtree напридумывали, которые до сих пор не очень юзабельны.

kamre ★★★
()
Ответ на: комментарий от kamre

Это не полезная фича, это зло, провоцирующее людей на очень, очень паршивую архитектуру. За это руки отрывать надо. В DVCS такой возможности нет, не будет и не должно быть by design, и это сознательное архитектурное решение.

anonymous
()
Ответ на: комментарий от anonymous

«освоить» в смысле «заучить пяток команд» или «быть в состоянии осмысленно адаптировать workflow под изменившиеся требования»? если первое — согласен, если второе — разница, мягко говоря, есть.

littlechris ★★★
()
Ответ на: комментарий от littlechris

ВНЕЗАПНО, я знаком с DVCS, отличными от git. Но когда сравнивают CVCS и DVCS мне хочется взять и... ну ты понел. Это как сравнивать ужа с ежом - да, это животные.... но на этом сходство заканчивается :-)

Pinkbyte ★★★★★
()
Ответ на: комментарий от littlechris

Нет, я имею в виду ПОЛНОСТЬЮ освоить.

anonymous
()
Ответ на: комментарий от hobbit

git и коммитить из него в svn

А КАК ЭТО???

man git-svn

Я так и делаю, ибо переносить фиксы из веток в trunk в svn — это адъ и израиль. git cherry-pick рулит и педалит.

akk ★★★★★
()
Ответ на: комментарий от anonymous

Так что, не надо нанимать лиц с IQ меньше чем 100 единиц. Их вообще никуда не надо нанимать

Людей, которые верят, что этот ваш IQ действительно отражает умственные способности человека, действительно вообще никуда не надо нанимать.

hobbit ★★★★★
()
Ответ на: комментарий от anonymous

Это не полезная фича, это зло, провоцирующее людей на очень, очень паршивую архитектуру.

Аргументы будут?

hobbit ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.