Проект KDE перешел на Subversion

<offtop>
А где бы можно посмотреть график запланированного выпуска новых версий KDE?
</offtop>

посмотреть что планируют нового в ветке 3.4 можно тут

http://developer.kde.org/development-versions/

Вот выйдет 4.0 - посмотрим на это =))

т. е. планируют:) ? оно уже все реализованно, дальше в 3.4 только фиксы будут

Скоро что ли KDE 4.0 выйдет???

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

Кстати, по ссылке нет ни слова о том, чем же svn лучше cvs. Утверждается лишь, что ВЕТКИ (branches) "сосут" (sic) в cvs, однако тут же делается оговорка, что они точно так же "сосут" в svn.

> Скоро что ли KDE 4.0 выйдет???

Думаю, что не раньше чем Qt 4.0. И я бы потерпел до 4.0.1 хотя бы. А то уж больно новое там все будет...

> Новый репозитарий доступен через svn.kde.org

На самом деле, через websvn.kde.org

у мня qt 4 beta 2 не скомпилилась.... долго компилилась и гдето через часика 3 отвалилась с ерором ;(

cvs is not a transactional source control system

> На самом деле, через websvn.kde.org

На самом деле websvn.kde.org сделали для таких как ты, которые любую ссылку тыкают в браузер, не догадываясь что это значит.

Ну еще websvn может заюзать могут тем кому надо один файлик быстро стянуть и то не факт...

Вы ей пользовались? Чем локинг не устраивает?

> p.s: складывается мнение, что cvs не подходит для крупных проектов

конечно не подходит - попробуйте сделать большой checkin (и параллельно кто-нибудь checkout), или попройте поудалять файлы проекта (attic, фу), или переименовать файл с сохранением истории (то в чем сейчас нуждается kde - у них грядет большая реструктуризация кода всвязи с переходом на qt4).

А транзакции рулят, хотя и у svn есть недоработки, например переименование файла сейчас фактически delete+add с сохранением истории, но в скором будущем обещают добавить нормальный rename/move

Для меня пока что только один плюс- я смог легко это дело заставить через http-proxy работать, чего так и не удалось добиться от cvs (может что-то недочитал).

Как минимум, версионированием директорий. С CVS получается так: - ты скоммитил набор файлов и получил релиз; - ты релиз отбранчил и начал развивать дальше; - и тут тебе понадобилось переименовать файл в связи с реструктуризацией кода, например.

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

если ты делаешь его копию, а старый удаляешь - ты теряешь историю изменений.

Кроме того, у svn гораздо более удобный синтаксис многих команд. Взять хотя бы svn status. Ты вот пробовал хоть раз cvs status натравить на каталог из хотя бы 10-20 файлов, чтобы быстро понять, какие файлы изменились и как?

это не недоработки. В противном случае ты не сможешь вытащить этот же файл предыдущими бранчами.

> Кроме того, у svn гораздо более удобный синтаксис многих команд

Ерунда всё это. На самом деле сменили шило на мыло. При чём на дерьмовое
мыло. Они в принципе одинаковы. Все преимущества Subversion (в виде
костылей) гасятся его недостатками. Arch надо было заюзать.

>Кстати, по ссылке нет ни слова о том, чем же svn лучше cvs.

Личные ощущения:

1) Ветки/таги проще. Не нужно мыслить в двух измерениях.

2) Все изменения версионируются.

3) Аттрибуты. Для целей автоматизации всяческих процессов - самое оно.

Ну и еще всяческие мелочи.

>Ерунда всё это. На самом деле сменили шило на мыло. При чём на дерьмовое мыло. Они в принципе одинаковы. Все преимущества Subversion (в виде костылей) гасятся его недостатками. Arch надо было заюзать.

Не стесняемся аргументировать.

Что-то долго она у Вас компилировалась, у меня минут чезер 20 отвелилась :) Там в каком-то месте забыли написать #include <qevent.h>

У меня сложилось впечатление, что в CVS нет команды чтобы
посмотреть список всех доступных бранчей.
Знатоки, прав ли я ???

К сведению тех, кому не нравится SVN
Эту систему пишут те-же люди, которые написали CVS
И недостатки CVS они знают куда лучше анонимусов с ЛОР'а, потому и начали писать новую систему
Что касается отстойности SVN по сравнению с остальными системами (arch, etc), то советую посмотреть сюда http://better-scm.berlios.de/comparison/comparison.html

1 Repository Operations

Atomic Commits
CVS: No. CVS commits are not atomic.
Arch: Yes. Commits are atomic.
Subversion: Commits are atomic.

Files and Directories Moves or Renames
CVS: No. Renames are not supported and a manual one may break history in two.
Arch: Yes. Renames are supported.
Subversion: Yes. Renames are supported.

File and Directories Copies
CVS: No. Copies are not supported.
Arch: No. Copies of files and directory structures are not supported.
Subversion: Yes. And it's a very cheap operation (O(1)) that is also utilized for branching

Remote Repository Replication
CVS: No.
Arch: Yes.
Subversion: Indirectly, by using Chia-Ling Kao's SVN::Mirror add-on or Shlomi Fish' svn-push utility.

Propagating Changes to Parent Repositories
CVS:No.
Arch: Yes.
Subversion: Yes, using either Chia-Ling Kao's SVN::Mirror script or the svn-push utility by Shlomi Fish.

Repository Permissions
CVS Limited. "pre-commit hook scripts" can be used to implement various permissions systems.
Arch Yes. It is possible to define permissions on access to different parts of a remote repository based on the permission systems of the underlying protocol.
Subversion Yes. The WebDAV-based service supports defining HTTP permissions for various directories of the repository.

Changesets' Support
CVS No. Changes are file-specific.
Arch Yes. Changesets are supported.
Subversion Partial support. There are implicit changeset that are generated on each commit.

Tracking Line-wise File History
CVS Yes. cvs annotate
Arch Not in the command line client, but ViewARCH, a web-interface for Arch, has it.
Subversion Yes. (svn blame)

> Эту систему пишут те-же люди, которые написали CVS
И недостатки CVS они знают куда лучше анонимусов с ЛОР'а

Опыт показывает, что не может одна и та же команда написать что-то
_принципиально_ лучшее. Она может написать что-то большее по размеру,
более жирное и глючное, с бОльшими проблемами в безопасности и т.п.
Глядим на subversion и наблюдаем - так оно и есть...

Remote Repository Replication
Subversion: Indirectly, by using Chia-Ling Kao

Костыль

Propagating Changes to Parent Repositories
Subversion: Yes, using either Chia-Ling Kao

Костыль

Repository Permissions
Subversion Yes. The WebDAV-based service supports

Костыль

Changesets' Support
Subversion Partial support.

Костыль

С этой точки зрения любой плагин, позволяющий добавлять фунциональность - костыль %). Давайте наколбасим все и сразу и сделаем один большой исполняемый файл :)
Заметь - эти "костыли", как ты говоришь - в основном (разве что кроме Changesets' Support) касаются распределенных репозиториев. Так и цели такой не ставилось при разработке. Что касается Repository Permissions, то я не вижу проблемы - есть система версионного контроля, поверх работают транспорты (апач например), которые и реализуют нужные Permissions. На скорости работы это не сказывается, гибкости и удобства добавляет - в чем проблема-то. Тебе вот в arch NTLM аутентификацию в связке с AD чего прикрутить стоит ? А мне просто модуль к апачу подключить.
Сабвершн - хорошая система. удобная, гибкая. Проблем с безопасностью я там не наблюдаю - багфиксы выходят вовремя, да и не много их
Если отбросить распределенные репозитории, то в плюс можно записать хорошую документацию и большое количество клиентов под многие платформы. А это значит, что скорость обучения работы для свн высокая -> работа с ней получается дешевле. Попробуй обучи человек 20 к примеру. А для вин-пользователей удобный гуи интерфейс так вообще выходит на первое место. Особенно если это дизайнеры, переводчики и т.д

> С этой точки зрения любой плагин, позволяющий добавлять фунциональность - костыль %).

Нет, это разные вещи. Костыль нельзя спутать с плагином.

>>Remote Repository Replication >>Subversion: Indirectly, by using Chia-Ling Kao

>Костыль

Subversion в первую очередь система с центральным репозиторием. Хотя фича полезная.

>>Propagating Changes to Parent Repositories >>Subversion: Yes, using either Chia-Ling Kao

>Костыль

Смотри выше.

>>Repository Permissions >>Subversion Yes. The WebDAV-based service supports

>Костыль

Есть в планах. В CVS, кстати, и того хуже. Arch, насколько я понял, использует тот же подход, что и Subversion. В общем, вполне практичное решение :)

>>Changesets' Support >>Subversion Partial support.

>Костыль

Не очень понял, какая функциональность подразумевается.

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

Своей задаче - свой инструмент. Для моих домашних проектов, например, Arch я бы использовать не стал - не нужно. Слишком сложно. Мои нужды полностью покрываются Subversion-ом.

В любом случае, Subversion еще относительно молод и большая часть функциональности пока еще только задумывается.

Кстати, вот полезная статья:

http://www.dwheeler.com/essays/scm.html

> Давай ты приведешь в пример систему которая лучше Subversion

arch

> Для моих домашних проектов, например, Arch я бы использовать не стал - не нужно. Слишком сложно.

Для твоих проектов CVS - самое то. Для больших и сложных - arch.
Отсюда вопрос - кому нужен в таком случае Subversion?

>> Давай ты приведешь в пример систему которая лучше Subversion

>arch

Не буду пересказывать статью, приведенную выше, это будет плагиат. Прочитай ее сам :)

Кстати, могу назвать пару минусов из-за которых я похоже выберу Monotone, а не Arch в качестве распределенной VCS.

1) Можно сказать, не работает на Win32. На середине туториала выдал - "слишком длинный путь"

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

3) Субъективно: старая документация. В туториале используется пара команд, которые уже куда-то переименовали.

4) Совсем субъективно: отношение к пользователю. Сайт Arch - полный отстой. Пользоваться продуктом после такого сайта совсем не хочется (что, конечно, не отменяет его возможностей :) )

>Для твоих проектов CVS - самое то.

Да? А что делать с трупиками в репозитории? С переносом/копированием файлов? Потом, ветки в CVS однозначно хуже. Что делать с аттрибутами? С кривой обработкой тектовых/бинарных файлов? Что-то не вижу для себя плюсов CVS. Никаких, абсолютно.

>Для больших и сложных - arch.

>Отсюда вопрос - кому нужен в таком случае Subversion?

Как минимум мне :) Короче, читай статью.