Вышел Subversion 1.6 и TortoiseSVN 1.6

[Paul]

Дык меньше дня с релиза прошло, добавят ещё, я думаю.

[Paul]

Дык соберите из сорцов.

[Sindorian]

и преврати систему в слаку %)

[differentlocal]

А собрать .rpm религия не позволяет? =)

[kai]

Блин, собери из сорцов rpm. Что мешает?

[efoxxi]

Тем временем пользователи винды тупо качают .msi и ничего не компилят, к примеру вот отсюда:
www.sliksvn.com/en/download

[non7top]

про тупо это метко подмечено

[non7top]

Да, вендузятники знают толк в извращениях. Обычные люди напишут что-то вроде apt-get upgrade и все как надо обновится. «Тупо» — не наш выбор.

[kai]

Бедняги.

[efoxxi]

Остальные просто уже перешли c SVN на Git/Mercurial/Bazaar
Не каждому понравится, когда в каждом каталоге создаётся каталог .svn

[shuvalov]

и что же в этом ужасного?

[Swappp]

Это вещи немного разные. Цель то одна, контроль версий, но SVN централизованный, а перечисленные децентрализованные. Все зависит от характера разработки и взаимодействия разработчиков. Пихать всюду Git не надо. А аргумент про .svn конечно смешной :)

[chanaev]

Вот именно тупо (
Жду — не дождусь, когда они обновление человеческое прикрутят уже.
Очень напрягает деинсталить, ребутить, инсталить…

[zerkms]

зачем деинсталлить и ребутить?

[chanaev]

А иначе не получается. Просит ребутнуться.

[zerkms]

ну и что, что просит.

[slyder]

отличная новость! очень не хватало экстерналов для файлов…
а вот зачем относительные пути?
/me полез гуглить =)

[Paul]

Идея в том, что вы можете сказать «это путь относительно repository root» не завязываясь на этот самый root.
Подробнее.

[scazy]

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

[taxigy]

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

[scazy]

по работе работаем над проектами группами в несколько человек, при одновременном редактировании одного файла разными людьми, и последущем commit — встроенный merge не справляется со сложным анализом и поиском изменений в исходниках, а предпочитает создать кучу файлов, по одному на каждого пользователя и типа «разгребайте» ваше говно ребятки сами, я пас

[brook]

Что же это за файл у вас такой — что все одновременно ведут на нём разработку, аж группами. Прям каждую строку файла все усиленно меняют? Я боюсь вам стоит задуматься об организации совместной работы — svn тут не виноват.

[scazy]

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

[Paul]

Это обычное раздолбайство, когда команда не может скоординироваться и несколько человек делают одно и то же.

[Paul]

Кроме того, если 2 человека исправили файл в одном и том же месте, ни один мега-интеллектуальный мержер не сможет разрешить конфликт автоматически. Так что я честно говоря не понимаю, чем вы недовольны.

[imil]

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

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

[googol]

Это *необычная* ситуация. Про координацию сказали выше.

[taxigy]

Такое происходит только в том случае, если редактируемые разными людьми участки кода находятся очень сильно рядом, если даже не одни и те же (привет, Капитан Очевидность). Сама система Subversion — она же не претендует на звание офигительно интеллектуальной, способной смерджить все то, что решила закоммитить хренова туча народу. Просто ну, знаете, обычный такой мердж…

[googol]

В Subversion довольно неплохой merge btw — он мержит все что сможет а что не сможет — добавляет маркеры.
Если вам станет легче от этого — то в Perforce мерж куда хуже, если он не может смержить файл; он вообще его не изменяет и пользователь должен смержить *все* сам.

[ZooKeeper]

Прорыва как с 1.5 похоже не случилось…