Забыл сказать про лицензию - лицензия типа Apache/BSD. :-)

И это.. начиная с версии 0.14 пользую (года два уж) - ни одного серьёзного глюка не было.

Общий вопрос.

Хочу перейти с CVS на subversion.

Как группе разработчиков в subj открыть доступ на чтение/запись только для отдельных файлов / директорий

Хранит ли subversion "chmod" / "chgrp" файлов?

emacs умеет с subversion работать?

Ну может и не плохая система, но т.к. мой проект лежит на SF то пока сохраним верность CVS.

Это возможно, используя mod_authz_svn, см. http://svnbook.red-bean.com/html-chunk/ch06s04.html#svn-ch-6-sect-4.4.2

> Как группе разработчиков в subj открыть доступ на чтение/запись
> только для отдельных файлов / директорий

1) Либо с использованием специального апачевого модуля mod_authz_svn.so - тогда список пользователей, их групп и прав доступа хранится в специальном файле.
Способ характеризуется невозможностью дать read-only доступ анонимусам (поправьте, если к 1.0 такая возможность появилась!)

2) Либо с использованием встроенных средств контроля доступа сервера Apache. Тут и LDAP, и через sspi - масса вариантов. Лично мне хватает обычного passwd файла и пары строчек в .htaccess.

Anyway контроль доступа производится на уровне разбора url-а, так что логичное, не помоечное расположение файлов и их групп в репозитории облегчит задачу контроля доступа.

> Хранит ли subversion "chmod" / "chgrp" файлов?

Непосредственно внутри базы (к слову в качестве бэкенда Subversion использует Berkeley DB) ни список пользователей, ни права доступа не хранятся. Увы.

> Это возможно, используя mod_authz_svn, см. http://svnbook.red-bean.com/html-chunk/ch06s04.html#svn-ch-6-sect-4.4.2

Да, но можно использовать стандартную директиву апача LIMIT.
<Strongly IMHO>
Limit удобнее
</Strongly IMHO>

под Слакой пускали уже?

>под Слакой пускали уже?

а что такое "Слака" ?

ну, я создал репозиторий

svnadmin create /mnt/data/repos

А дальше что? Чего писать, кому жаловаться?

Ленивый склеротический чайник

>>под Слакой пускали уже?

>а что такое "Слака" ?

Как, вы не знаете, что такое Слака?

Слака - это такой недо-дистрибутив, используемый самой красноглазой частью публики ЛОР.

у него по идее должны быть http досутп (это надо включать в апач специальный модуль?), ssh доступ и просто svn доступ. Как завести новых юзеров. Как при заведении нового юзера выдать ему права на какуюто его диреткорию. Вообще cvs нигода раньше не пользовался, но возникла проблема с исправлениями и новыми фишками при написании програм...

спасибо кто поможет люди добрые сами мы не местные.

Ленивый склеротический чайник

ничего не втыкаю...

как хоть показать то, что туда залил? типа залил и фсе.

Ленивый склеротический чайник (вы на меня не обижайтесь!!)

>И это.. начиная с версии 0.14 пользую (года два уж) - ни одного серьёзного глюка не было.

вот только база у него периодически рушится и приходится svnadmin recover делать. 1.0.0 интересно уже стабильно работает?

>emacs умеет с subversion работать?

да

бля там же отличный хелп идёт в поставке смотри в сторону svn import; svn co; svn up ну и так далее вообщем svn help

> Ну может и не плохая система, но т.к. мой проект лежит на SF то пока сохраним верность CVS.

На sunsite.dk обещали subversion поставить в ближайшее время. Поэтому я верность BitKeeper'у хранить буду не долго. Дома использу subversion начиная с 0.37.0 (release candidat). Мне нравится, но по bk citool я пожалуй буду скучать...

Сказал на сайте subversion search по слову emacs - нашёл только одно упоминание по этому вопросу, да и то в контексте in theory. Собственно говоря, где информация?

А что значит "Please bear with us, while we try to survive Slashdot..." на каждой странице сайта?

svn import $HOME/my_project/ file:///mnt/data/repos

В slackware работает нормально.

Лучше на emacswiki сказать subversion.

При использовании db4-4.0.x иногда рушится, при db4-4.1.25 и выше - нет.

Диментий! Как там дела с русским переводом Subversion Book?

А чем оно лучше GNU Arch?

Отож.:-)

Я пока нашел только 2 преимущества(насколько существенных - судите сами):

1. активнее разрабатывается

2. более cvs-совместимые команды

Все остальное не лучше.

>Сказал на сайте subversion search по слову emacs - нашёл только одно упоминание по этому вопросу, да и то в контексте in theory. Собственно говоря, где информация?


$dpkg -S usr/share/emacs/site-lisp/vc-svn.el
subversion: /usr/share/emacs/site-lisp/vc-svn.el


то есть соответствующий модуль входит в состав subversion'а

дык у меня как раз db4-4.1.25

> дык у меня как раз db4-4.1.25
Дык она же не рекомендуется. В девелоперском листе давно
говорится, что db-4.1.x не рекомендуется. Используй 4.2,
там и логи могут автоматически удаляться

Emacs and Subversion

поставил новенкий SVN в Gentoo и он при установке среди прочего выдал выдал * Adding /usr/share/emacs/site-lisp/70svn-gentoo.el... в много чего есть вроде-бы все необходимое

> Диментий! Как там дела с русским переводом Subversion Book?

Торжественно обещаю, перед строем анонимусов, эдак за недельку добить. Новая работа - не до того было.

>> Диментий! Как там дела с русским переводом Subversion Book?

>Торжественно обещаю, перед строем анонимусов, эдак за недельку >добить. Новая работа - не до того было.

Строй анонимусов облизнулся в предвкушении

Подскажите, плиз, где взять .spec или .src.rpm?

все же зачем-то на 6 пакетов ее порубили?

по линкам только сорцы в .tar, и бинарники в .rpm (и только 0.37 версия)

>Подскажите, плиз, где взять .spec или .src.rpm?

>все же зачем-то на 6 пакетов ее порубили?

>по линкам только сорцы в .tar, и бинарники в .rpm (и только 0.37 версия)

Ты будешь смеяться, но в тарболле есть .spec-файлы, смотреть
в packages/rpm ;) Но построение готовых RPM - процесс
нетривиальный, требует довольно много devel-пакетов,
так что лучше подождать, пока классный парень David Summers
сделает работу за нас ;)

А разбили на несколько пакетов потому, что некоторые
(по моему, subversion-server) требуют Apache 2.0

А версия 0.37 от 1.0.0 почти ничем не отличается (я сам
до сих пор пользую 0.35.1, полет нормальный).

"Все остальное не лучше" - значит ли это, что все остальное - хуже?

И еще - как сапгрейдить cvs repository на эту игрушечку? В конторе уже есть cvs, хочется освоить новую технологию. Если это ЧАВО, просьба не обзываться:)

См. папку cvs2svn/ в дереве subversion.

>Все остальное не лучше" - значит ли это, что все остальное - хуже?

Ну, в общем, да - кроме одной важной вещи: Arch невозможно использовать. По крайней мере, я не смог - эти его имена с двумя минусами и фигурными скобками, десятки команд, невозможность сделать простые вещи типа "просмотреть историю файла"... И на винде он не работал до последнего времени, не знаю, как сейчас.

>И еще - как сапгрейдить cvs repository на эту игрушечку? В >конторе уже есть cvs, хочется освоить новую технологию. Если >это ЧАВО, просьба не обзываться:)

В дистрибутиве есть такой тул - cvs2svn.py. И в FAQ это должно быть.

>"Все остальное не лучше" - значит ли это, что все остальное - хуже?

Не все:-). Некоторые вещи эквивалентны. Некоторые хуже.

>хочется освоить новую технологию

IMO Arch существенно лучше "архитектурно". Потому советовал бы осваивать его. Хотя у нас пока CVS :-).

Нарываюсь на флейм. Можно раскрыть: "Arch существенно лучше архитектурно"?

>Нарываюсь на флейм. Можно раскрыть: "Arch существенно лучше архитектурно"?

http://wiki.gnuarch.org/
Там подробно объяснят, что Arch - круче вареных яиц и
выше звезд. На первой странице линк сравнение с Subversion
и CVS - хотя в его объективности я сомневаюсь. Была еще очень
интересная статья Лорда "Diagnosing SVN", тоже должна быть на
этом сайте или в Google

Если кратко - то "changesets are the one true way",
а Subversion их не поддерживает (нет, atomic commits
не катят за отмазку).

По функциональности они близки - задача то одна. Но:

AFAIK для создания arch потребовалось сильно меньше работы - как я понимаю он написан одним человеком за меньшее время. Сойдет за показатель "большей архитектурной правильности"? :-)

В нем просто нет ненужных сущностей -

1. Нет транспортного протокола - работает поверх всего, что файлы передает.

2. Нет выделеной базы данных - нечего устанавливать и чинить(см. выше), все в "просто файликах" лежит.

3. Нет центрального сервера -> лучше "распределяется" - можно держать много независимых архивов и работать при отсутствии связи с сервером.

В общем "unix-way" в почти полный рост:-).

Однако, стоит признать, что Arch-евы имена файлов склонны вызывать легкое раздражение(по крайней мере поначалу). Его склонность к использованию символов '=+' в начале имен файлов меня пока не вдохновляет (мягко говоря).

Меня это тоже поначалу злило. Через некоторое время я с удивлением обнаружил, что в работе это не мешает (но злиться не перестал). Так что, use arch, guys...

> "Все остальное не лучше" - значит ли это, что все остальное - хуже?

> И еще - как сапгрейдить cvs repository на эту игрушечку? В конторе уже есть cvs, хочется освоить новую технологию. Если это ЧАВО, просьба не обзываться:)

http://lev.serebryakov.spb.ru/refinecvs/

> Я пока нашел только 2 преимущества

Ещё парочка:

3) Работает под "оффтопиком" - и клиентская и серверная части.
4) Наличие функционально законченных либ для работы с репозиторием и рабочей копией - простота создания альтернативных клиентов.

>> И еще - как сапгрейдить cvs repository на эту игрушечку?
> См. папку cvs2svn/ в дереве subversion.

Верно. Но ещё есть RefineCVS от Льва Серебрякова, правда я лично не пробовал. Живёт здесь:
http://lev.serebryakov.spb.ru/refinecvs/

По словам автора, это скрипт на perl (в противоположность питоновскому cvs2svn), особенность - пока держит всю структуру репозитория в памяти и поэтому не может обрабатывать очень большие репозитории (cvs2svn разводит тучу временных файлов, но его можно даже застопить и потом перезапустить с прерванного места). Утверждается, что по логике RefiveCVS "умнее" (оба конвертера стараются сфантазировать, какие изменения внесены в cvs-репозиторий "за один раз" и конвертируют их в один атомарный коммит).

>Работает под "оффтопиком" - и клиентская и серверная части.

Приношу свои извинения за пропущеную дезинформацию - это я не со зла, а не заметил, ибо у этого серверная часть тоже "работает"(нет её потому что). А с клиентской SFU должен помочь:-).

>Наличие функционально законченных либ для работы с репозиторием и рабочей копией.

Тут тоже все довольно просто.

1. Есть документ, описывающий "структуру репозитория", дальше: zlib, open/read/write, и т.д. Работы больше, правда.

2. Берем исходники, и вырезаем из них нужный API - наверняка его легко найти.

3. (-:Простейший вариант:-) а popen на что?

1. Под offtopic arch прекрасно работает под SFU.

2. В арче инкрементальная база данных - коррапт истории маловероятен.

3. Merge бранчей в арче настоящий, а не рахитский как в SV. Распределенные репозитории рулят!

4. Реально работать можно только имея локальную копию базы, иначе очень медленно. Вообще по умолчанию безумный тормозеж. (Попробуйте сделать get tla-tools и порадуйтесь скорости! И это чтобы скачать десяток sh файлов - я фигею!). Делать регулярно ручками cacherev скучно. revision-library хороша только для крохотных проектов - если кто не знает - это все ревижены в туче поддиректорий с экономией места хардлинками. Почему при get базой выбрана первая версия, а не последняя, не понятно. В форуме постоянно спрашивают, а Тому нечего сказать. Перемудрил при проектировании имхо.

5. Нельзя сделать get отдельному файлу или под-директории :( Мета-проекты отстой имхо.

6. Гуру Том с огромным самомнением постоянно просящий денег мне не симпатичен

> Берем исходники, и вырезаем из них нужный API - наверняка его легко
> найти

Это всё здорово, но как-то не говорит о "красивой архитектуре". По крайней мере в части реализации, может идея-то и здравая. Это _не_ критика арча - я его вообще не видел живьём :) Просто попытка разобраться. Для каждого релиза svn например тесты имеются - для либ отдельно и для продукта в целом. Т.е. имеет место нормальный промышленный подход к разработке. А про арч тут писали, что вот мол, быстро что-то "прикрутили" когда понадобилось - вроде электронную подпись изменений. Не хочется использовать то, к чему что-то "прикручивают" на ходу. Вот взять TortoiseSVN - виндовый svn-клиент. Всем хорош, только тоже всё "прикручивается" на коленке - то отдельные команды с русскими именами не работают, то ещё что-нибудь.... задалбывает временами.

Предупреждаю: я svn-а живьем тоже не видел - и мои суждения об нем основаны на документации, статьях, пр. Как впрочем и об arch-е(его я видел - но активно попользоваться еще не успел). Продолжим. Для разобраться(-:это не критика svn-а - просто так получилось:-)

>но как-то не говорит о "красивой архитектуре"

О красивой архитектуре может говорить отсутствие необходимости делать либы для работы с репозиторием и рабочей копией :-)(точнее это говорит об простой организации хранилища данных, что плюс)

>имеет место нормальный промышленный подход к разработке

А вот тут спорное место. Если за сравнимое время реализованы 2 эквивалентных проекта, причем первый - "нормальным промышленным методом" а второй нет - я скажу (очень рискуя оказаться правым), что первый разработан неправильно - ибо _доказано_ существует более простое(не требующее "промышленного" подхода) решение.

>Не хочется использовать то, к чему что-то "прикручивают" на ходу

Если проект достаточно "модульный" для прикручивания на ходу - это плюс ему. Редкий проектировщик может предусмотреть _все_ требования заранее. Посему лучшее, что он может сделать, это предусмотреть достаточную гибкость/модульность. А потом пусть дописывают. Т.е. это норма IMHO.

В общем мне дизайн arch-а нравится именно тем, что позволяет реализовать его на shell-скриптах + несколько утилит. А svn не нравиться тем, что для реализации клиента нужно прилинковать библиотеку для работы с репозиторием и рабочей копией. Может это извращенный вкус у меня такой:-?