Блин, только 1.4.1 скачал...

Подумываю компанией перейти с cvs на svn, народу надо будет раздавать ГУЁвину (как под Lin так и под Win).

Какую гуйню может порекомендовать многоуважаемый ALL? Нужно чтобы могла строить графическое отображение дерева (ствола, отходящих от него веток с метками и т.п.), как это умеют LinCVS, WinCVS.

kdesvn

> Какую гуйню может порекомендовать многоуважаемый ALL?

http://tortoisesvn.tigris.org/ под вин.

Так нету в Subversion никаких меток! ;)

l07, у Subversion нет таких меток, как в CVS, т.е. работа в Subversion идёт в едином дереве.

По-моему, это единственный существенный момент, могущий препятствовать переходу CVS->SVN.

Там нет меток или веток?;)

как вы себе представляете работу без "веток" ?

Насколько я знаю, там это производится копированием дерева на ФС.

http://svnbook.red-bean.com/nightly/en/index.html ответит на все ваши вопросы.

Просто я не понял реплики про "вся работа идет в одном дереве".

тогда уж лучше это:
http://svnbook.red-bean.com/nightly/ru/index.html

интересно, на sf.net svn обновят?.. Хотя я уже потихоньку на git переползаю...

kdesvn, rapidsvn... лично я использую (и очень рекомендую) kdesvn.

svn.sf.net

А Sourceforge разве на Subversion работает? Я думал он CVS хостинг раздаёт.

>Подумываю компанией перейти с cvs на svn, народу надо будет раздавать ГУЁвину (как под Lin так и под Win).

А я свою уже сагитировал и пересадил, пока они на CVS не успели! ;)

>Какую гуйню может порекомендовать многоуважаемый ALL? Нужно чтобы могла строить графическое отображение дерева (ствола, отходящих от него веток с метками и т.п.), как это умеют LinCVS, WinCVS.

Рекомендации те же: Linux - kdesvn (использует Kompare) - The best tool ever! Windows - TortoiseSVN (есть еще SmartSVN, но она платная).

>http://svnbook.red-bean.com/nightly/en/index.html ответит на все ваши вопросы.

Лучше уж это: http://svnbook.red-bean.com/nightly/ru/index.html ;)

>Там нет меток или веток?;)

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

Plugins for Eclipse : Subclipse, Subversive
Plugin for Netbeans,
Jira, Trac тоже хорошо рисуют дерево проекта в Subversion

нету именно _меток_

>Просто я не понял реплики про "вся работа идет в одном дереве".

Для чего использовался механизм _меток_ в cvs? Для двух целей:

* для присвоения символьных имён версиям содержимого репозитория

* для помещения временной работы вести в _отдельное_ файловом пространстве, отличном от основного.

В Subversion для той же цели приходится копировать ветку в другое место в том же дереве, и это происходит в _общем_ файловом пространстве.

Именно поэтому в Subversion есть "стандартная" структура: <pre> +branches +tags +trunk </pre>

>Нужно чтобы могла строить графическое отображение дерева (ствола, отходящих от него веток с метками и т.п.),

Тут у svn есть некоторая проблема.

Чтобы проследить всю историю некоторого файла (имеется ввиду его копирование), subversion должен просмотреть все версии всего репозитория. Делает он это, в принципе, достаточно быстро: у меня текущий revision что-то типа 500000 и на рисования дерева уходит не больше суток.

И чем svn лучше git?

> И чем svn лучше git?

Навскидку:

1. централизация (это и плюс и минус)

2. идейно ближе к CVS => миграция легче

3. разумный трафик

4. работает под вражескими системами без cygwin-костылей

> А Sourceforge разве на Subversion работает? Я думал он CVS хостинг раздаёт.

И то, и то, давно уже.

> И чем svn лучше git?

А он не лучше, у них разные применения. Плохо только то, что одно ванильное ядро в git'е, а форки и в git и в svn и в cvs.... Но тут опять ж подход git наиболее удобен, как патче-ориентированный и децентрализованный.

Под Windows гуйня - однозначно TortoiseSVN.Правда, меня несколько пугают замашки разработчиков (собирается он исключительно под Visual Studio и никак не ниже 2005-й), но если вы не хотите копаться в их исходниках - это не важно. И ещё мне пришлось взять не самую последнюю версию - последняя жёстко хотела последний же Microsoft Installer, что выполнялось не на всех обSVNячиваемых машинах. Но работает. ...А под линуксом меня вполне устраивает клиент командной строки. svn update и "погнали наши городских..."

О! Как раз вовремя.. ;-)

Тогда лучше не про git, а про monotone спрашивать. Архитектура GIT уж очень сильно привязывалась к модели разработки ядра. Ребята, используйте monotone.

> Ребята, используйте monotone.

Только не этот тормоз! %-/ Юзайте Darcs или Mercurial, кому что нравится. =)

> Ребята, используйте monotone.

У вас много свободного времени? :)

Свободного времени не много. Но monotone дает мне возможность вести разработку не имея доступа к репозиторию и спокойно мерджить в него мои изменения.

> Но monotone дает мне возможность вести разработку не имея доступа к репозиторию и спокойно мерджить в него мои изменения.

Это ключевая особенность _любой_ распределённой системы, и даже для сабжа есть специальный костылик: http://svk.elixus.org/. =)

Костыль-костылем, но не часть архитектуры.

> Костыль-костылем, но не часть архитектуры.

git давно видел?

SmartSVN foundation version ни разу не платная. Умеет ssh+svn, ssl+svn, минус - на жабе. Под linux еще есть хороший клиент eSvn, только я ниасилил заставить его работать через ssh+svn, через ssl+svn вроде пашет.

Я выше про git уже писал.

Я могу тебя порадовать что такая нехилая коммерческая тулза как Clearcase на невполне релальном проекте (слили четыре проекта в один)
примерно с ~3000 версий рисовала дерево больше чем рабочий день (те я ее просто прибил вечерм)

revision 500.000 это бред полный. даже если каждый день 100 девелоперов делают по 5 коммитов _одного_ и _тогоже_ файла то что бы сделать 500.000 им нужно не разгибаясь пахать четыре год...

короче - гон.

dimav123, не позорьтесь.

> evision 500.000 это бред полный. даже если каждый день 100 девелоперов делают по 5 коммитов _одного_ и _тогоже_ файла то что бы сделать 500.000 им нужно не разгибаясь пахать четыре год...

1. В SVN номер ревизии - сквозной, т.е. обновляется на каждом коммите. 2. Вы не учитываете рефакторинг (Sublcipse, к примеру, коммиттит каждый измененный файл отдельно) и мерж между бранчами.

>> Ребята, используйте monotone.

> Только не этот тормоз! %-/ Юзайте Darcs или Mercurial, кому что нравится. =)

Вы чего-то не то с ним делаете.

У меня monotone быстрее работает. darcs быстрее только на маленьких пректах.

Кроме того monotone толково работает с бинарниками. Если бинарников много то monotone вне конкуренции.

> Кроме того monotone толково работает с бинарниками. Если бинарников много то monotone вне конкуренции.

Хм.. а какого рода бинари имеет вообще смысл хранить в RCS??

А какой смысл их там не хранить? Например есть книга с кучей иллюстраций. Хачем я буду выкручиваться с хранением их отдельно есл monotone отлично работает с таким репозитарием.

> Кроме того monotone толково работает с бинарниками.

Интересно стало. А подробнее можно?

>> Кроме того monotone толково работает с бинарниками.

> Интересно стало. А подробнее можно?

Да ничего сложного. Различия делает xdelta.

> Различия делает xdelta.

И этим вы хотите нас удивить? :) По-моему, все, кроме мёртвого CVS, используют бинарные дельты. =)

еще раз 500000 коммитов. для одного (по утверждению анонимуса) файла для которого он строит дерево. нереально.

более того 500000 коммитов "всего" на негиганский (типа OS или office suite или SAP) проект который длится меньше двух лет также выглядят нереальными. см расклад выше.

даже с мержем и рефакторингом полмиллиона это много. этот код еще написать надо что бы рефакторить :) в двух годах рабочих дней где-то
560, 1000 коммитов в день?

В КДЕшном репозитории сейчас текущая ревизия 603634. http://websvn.kde.org/ Хотите сказать, у вас проект размером и возрастом почти как КДЕ? :)

Но при этом нормально работает. И не тормозит.

А вообще хуками привязать можно любой diff. Например для xml файлов обычный diff практически бесполезен и использовать вместо него xmldiff очень полезно.

Я ничего не имею против других RCS. Просто называть monotone тормозом грешить против истины. Darcs тоже хорош но мне меньше подходит.

> Но при этом нормально работает. И не тормозит.

Не верю. Если клонирование репозитория занимает несколько часов, это "не тормозит"? Хозяева репозиториев даже выкладывают ежедневные снапшоты, чтоб люди не мучались.

А если всё равно не верите, попробуйте взять tailor и загнать в monotone исходники ядра, со всей историей. К концу второго-третьего дня ожидания сами всё поймёте. :)

А давайте не путать теплое с мягким и не приписывать монотону тормоза тайлора при конвертировании репозитория? Я пользуюсь tailor достаточно часто и что он медленно работает я в курсе.

Возьмите тогда для проверки монотоноский репозиторий. И на нем экспериментируйте.

> Возьмите тогда для проверки монотоноский репозиторий. И на нем экспериментируйте.

Спасибо за идею. Решил провести сравнение скорости клонирования репозиториев Monotone и Mercurial. Для этого скачал монотоновский репозиторий (8057 ревизий, размер базы около 100Мб), для сравнения взял xen-3.0.3 (http://xenbits2.xensource.com/xen-3.0.3-testing.hg, 11774 ревизии, размер каталога .hg - тоже около 100Мб).