Вышла Subversion 1.1.0

Кто как думает, возможен ли в ближайшем будущем переход таких сервисов, как sourceforge, savannah и gna на что-либо отличное от cvs?

У Berlios уже есть Subversion.

jakarta.apache.org уже на svn

> возможен ли в ближайшем будущем переход таких сервисов, как sourceforge, savannah

Невозможен поскольку есть GNU Arch.

> Кто как думает, возможен ли в ближайшем будущем переход таких > сервисов, как sourceforge, savannah и gna на что-либо
> отличное от cvs?

Если тебя интересуют именно эти сервисы, то ХЗ. SF уже пару
лет назад издавала по поводу перехода какие-то звуки, но так
и не перешла.

Если же вопрос по поводу хостинга проектов под SVN, то
тебе сюда:

http://subversion.tigris.org/propaganda.html

Там есть "Sites that Offer Subversion Hosting"

--tailgunner

>> возможен ли в ближайшем будущем переход таких сервисов, как sourceforge, savannah

>Невозможен поскольку есть GNU Arch.

Он уж 2 года как есть, а число Apache с установленной
поддержкой Subversion все растет.

И вообще - при использовании GNU Arch централизованные
системы вроде sourceforge и savannah не нужны! ;)

>И вообще - при использовании GNU Arch централизованные системы вроде sourceforge и savannah не нужны! ;)

Имеется в виду то, что он использует простой ftp протокол? Ну это конечно плюс, надо сказать. Но sf и savannah это не только cvs, но еще и www, ftp, bugtracking, forums, mailing lists, donation system... И все это в одном флаконе, уже настроено и не требует усилий для ввода всего этого барахла в эксплуатацию :-)

Я вот и спросил, возможен ли уход того же sf с cvs? Это ведь громадное количество проектов, мало того что сил и денег на это потребуется очень много, так еще и недовольные наверняка найдутся в большом количестве :-) А ведь cvs, по идее, и вправду уже морально устарел, хоть и привыкли к нему все...

(пост от 30.09.2004 19:10:36 - мой)

>> И вообще - при использовании GNU Arch централизованные
>> системы вроде sourceforge и savannah не нужны! ;)

>Имеется в виду то, что он использует простой ftp протокол? Ну это конечно плюс, надо сказать. Но sf и savannah
> это не только cvs, но еще и www, ftp, bugtracking, forums, mailing lists, donation system...

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

--tailgunner

Вот раз зашел разговор на эту тему скажите пожалуйста какие есть аргументы в пользу перехода с cvs на cvn?

> Вот раз зашел разговор на эту тему скажите пожалуйста какие есть аргументы в пользу перехода с cvs на cvn

Я сам CVS никогда не пользовался (начал пользоваться SVN с середины 2002), поэтому могу только дать тот же линк:
http://subversion.tigris.org/propaganda.html
там есть раздел User Testimonials. Как я понимаю, все тащатся от atomic commits (когда изменения в нескольких файлах
сохраняются как единое целое, с единым log message).
Я просто не понимаю, как можно _без_ этого. Еще народу нравится, что можно спокойно переименовывать файлы,
но, ИМХО, здесь SVN посасывает - делать merge средствами SVN в присуствии измененных переименованных файлов невозможно.
Так что никогда не переименовывай файлов на бранчах - дождись, пока все бранчи завершатся и останется только транк.

была ветка на ru.unix.prog - там достаточно много аргументов

>Вот раз зашел разговор на эту тему скажите пожалуйста какие есть аргументы в пользу перехода с cvs на cvn?

Вот сразу виден подход ни разу не копавшего CVS человека.

В принципе, работа CVS меня вполне устраивает, за исключением ОДНОГО БОЛЬШОГО МИНУСА CVS-a - отстутствие ACL-й... Я даже пытался восполнить это и переписать исходные коды CVS-а, но так руки не дошли, а потом увидел svn...

> В принципе, работа CVS меня вполне устраивает, за исключением
> ОДНОГО БОЛЬШОГО МИНУСА CVS-a - отстутствие ACL-й. Я даже
> пытался восполнить это и переписать исходные коды CVS-а, но
> так руки не дошли, а потом увидел svn...

И что случилось? В SVN тоже нет ACL... Или ты имеешь в виду
mod_svn_authz (или как там называется эта примочка для Apache)?

@fuzk:

Посмотри вот эту ссылку на предмет ACL: http://sourceforge.net/docman/display_doc.php?docid=772&group_id=1#script...

Ждём появления SVN в репозитарии слаки...

> У Berlios уже есть Subversion.
Угу - только у них руки так и не дошли его нормально настроить. Я пробовал с ним работать. Глючит "непадеццки" - вернулся на свой родной сервер, хоть и канал нетолстый, зато полный котроль.

>новый backend, позволяющий создавать репозитории
>на сетевых файловых системах,
Гм, Demetrio, ты точно уверен ?
Из релиза:
* new non-database repository back-end (libsvn_fs_fs)

Насколько я понял, это не на сетевых файловых системах, а просто на файловых системах (в документации на более ранние релизы четко указано, что на сетевых дисках репозитории работать не будут в силу ряда неустранимых проблем). Это альтернатива для тех, кто не любит или не хочет лишних _потенциальных_ проблем с BDB.
Данные сохраняются просто в файловой системе вместо базы данных, оставаясь, тем не менее, в бинарном формате.
Поскольку API subversion дает представление репозитория в виде ФС, то разработчикам добавить это ничего не стоило, вот и сделали по просьбе одного человека.

А кто знает, как файлы в SVN игнорить? механизм .cvsignore не работает.

В Subversion Book (http://svnbook.red-bean.com) все описано. Свойство svn:ignore на отдельные директории и параметр global-ignores в кофигурационном файле.

global-igonres НЕ РАБОТАЕТ НА ДОБАВЛЕНИЕ! а нафига мне в репозиторий *.bak импортить?

find <DIR> ! -iname '*.bak' | xargs svn add -N

>>новый backend, позволяющий создавать репозитории
>>на сетевых файловых системах,
>Гм, Demetrio, ты точно уверен ?
>Из релиза:
>* new non-database repository back-end (libsvn_fs_fs)

>Насколько я понял, это не на сетевых файловых системах, а >просто на файловых системах

(Я анонимус, запостивший новость)
Новый backend - это именно для создания репозиториев на
файловых системах, смонтированных через сеть - NFS, SMB.

> (в документации на более ранние релизы четко указано, что на
> сетевых дисках репозитории работать не будут в силу ряда
> неустранимых проблем). Это альтернатива для тех, кто не
> любит или не хочет лишних _потенциальных_ проблем с BDB
В документации сказано, что на сетевых дисках не будут работать
репозитории BDB, из-за проблем с реализацией mmap (который использует
BDB) в сетевых ФС.

http://web.mit.edu/ghudson/info/fsfs
http://subversion.tigris.org/svn_1.1_releasenotes.html

--tailgunner

Ты прав, спасибо за информацию. Тем лучше, больше возможностей, хороших и разных %)

> (Я анонимус, запостивший новость) > Новый backend - это именно для создания репозиториев на > файловых системах, смонтированных через сеть - NFS, SMB.

NFS, SMB это уже следствие хранения репозитория в файловой системы без dbd. А сделано именно хранение в файловой системе. Видимо ты никогда не имел проблем с нарушением базы данных с огромным репозиторием.

> NFS, SMB это уже следствие хранения репозитория в файловой
> системы без dbd. А сделано именно хранение в файловой
> системе. Видимо ты никогда не имел проблем с нарушением базы
> данных с огромным репозиторием.

Ты знал, ты знал ! ;) Впрочем, я и репозиториев больше 50М не имею.
А что в твоем понимании "огромный репозиторий"? В Sгимукышщт propaganda
я читал о репозитории Conectiva Linux на 30Г, и человек говорил, что
ни одного бита не потряли (хотя проблемы были, но он же и использует
SVN с августа 2002, это примерно 0.14)

Кстати, единственный раз, когда я попробовал использовать FSFS, у меня
туда загрузилось только пол-дампа одного из репозиториев.
С тех пор я ей не доверяю ;)

--tailgunner