The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"OpenNews: Децентрализованное будущее Subversion"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [ Отслеживать ]

"OpenNews: Децентрализованное будущее Subversion"  
Сообщение от opennews (ok) on 04-Май-08, 08:21 
SVN - централизованная система контроля версий, при создании которой главной целью бала разработка замены для CVS. Сейчас уже однозначно можно утверждать что цель достигнута и даже несколько перевыполнена: SVN хороший, простой инструмент, массово используемый, и при этом еще и бесплатный. SVN прекрасно работает с современной технологией разработки ПО, а методика работы с ним повышает качество кода, поскольку любой код обычно просматривает как минимум еще один человек кроме написавшего этот код.


Бен Коллинз-Сассман (Ben Collins-Sussman), создатель Subversion, поделился (http://blog.red-bean.com/sussman/?p=90) своими мыслями о будущем развитии Subversion, которое он видит в добавлении децентрализованных функций, но без полного ухода от централизованной модели.

Есть проблемы, обусловленные тем что SVN централизованная система, например если разработчик находится в самолете или на конференции, он может не иметь доступа к централизованному хранилищу, также неприятно что какая-то пр...

URL: http://blog.red-bean.com/sussman/?p=90
Новость: http://www.opennet.dev/opennews/art.shtml?num=15654

Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


2. "Децентрализованное будущее Subversion"  
Сообщение от denis_ka on 04-Май-08, 09:06 
половину утверждений не совсем правильны

>Они существенно сложнее в использовании чем централизованные.

не сложнее..

>Огромное (до сотни) количество команд управления.

одна команда bzr, или hg, которые практически повторяют svn

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

непонятно что имеется в виду, потому что предложение бред, может не так перевели с en.

>Провоцирующая легкость создания новой ветви проекта.

и?

>Децентрализованная модель не соответствует современной модели коммерческой разработки ПО.

тоже непонятно..
можно так выразится, открытые языки не соответствуют "современной модели коммерческой разработки ПО". Или открытые ОС не соответствуют "современной модели коммерческой разработки ПО".

git, bzr, hg, svn, cvs, vss - это просто инструменты. как их использовать, кто их использует,  и "современной модели коммерческой разработки ПО" - это разные вещи.

короче минусы децентрализованных не раскрыты...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Децентрализованное будущее Subversion"  
Сообщение от Дмитрий Ю. Карпов on 04-Май-08, 09:17 
>> Они существенно сложнее в использовании чем централизованные.
> не сложнее..

Сложнее - хотя бы потому, что нужно поддерживать синхронность нескольких хранилищ.

>> Поскольку можно вносить изменения не обращаясь к центральному хранилищу, повышается вероятность что внесенные изменения никто не просмотрит и ухудшится качество кода.
> непонятно что имеется в виду, потому что предложение бред, может не так перевели с en.

Всё довольно просто: Один из разработчиков вносит изменения в свою локальную копию проекта. Потом эти изменения рассылаются остальным участникам проекта. Чем больше хранилищ и чем протяжёнее граф синхронизации, тем больше вероятность, что одни разработчики работают с новой версией программы, а до других изменения ещё не дошли.

>> Провоцирующая легкость создания новой ветви проекта.
> и?

И плохо!

>> Децентрализованная модель не соответствует современной модели коммерческой разработки ПО.
> тоже непонятно.

Перевожу: коммерческие разработчики привыкли пользоваться централизованным хранением и не привыкли пользоваться распределённым хранением.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Децентрализованное будущее Subversion"  
Сообщение от denis_ka on 04-Май-08, 09:41 
>Сложнее - хотя бы потому, что нужно поддерживать синхронность нескольких хранилищ.

и в svn можно не обновляться и не синхронизироваться.  "и  как можно поддерживать синхронность нескольких рабочих каталогов, не понимаю" :-)

>Потом эти изменения рассылаются остальным участникам проекта.

зачем остальным?

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

Работать с децентрализованной системой можно по разному :-)

>Перевожу: коммерческие разработчики привыкли пользоваться централизованным хранением и не привыкли пользоваться распределённым хранением.

Перевожу:  коммерческие разработчики привыкли пользоваться ЧЕМ-ТО и не хотят переходить на новое ЧТО-ТО.


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Децентрализованное будущее Subversion"  
Сообщение от Nick email(??) on 04-Май-08, 14:06 
>выбрали один репозиторий главным (или выбрали управляющего, или иерархию владельцев кода), и
>туда сливаются патчи. а потом кому надо тот и обновляется. практически
>та же самая централизованная разработка :-)
>
>Работать с децентрализованной системой можно по разному :-)

вот вот.

Если инструмент создан быть децентрализованным - то его можно использовать и централизованно. Эту возможность никто у него не отнимает.

Более того, конкретно git способен эмулировать работу SVN или CVS серверов ;)

Т.е. это именно более "гибкая колбаса" :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Децентрализованное будущее Subversion"  
Сообщение от Nick email(??) on 04-Май-08, 13:08 
>>> Они существенно сложнее в использовании чем централизованные.
>> не сложнее..
>Сложнее - хотя бы потому, что нужно поддерживать синхронность нескольких хранилищ.

"нужно"?? Вы уверены, что вы слова не перепутали?
Кому нужно?

Они синкают удаленные репозитории по мере надобности. И нужно это именно тому, кто
забирает обновления. Т.е. активность проявляет тот, кому нужно.
По-моему все на своих местах.

Мье не вкурсе что такое децентрализованные средства разработки? (раз упоминаете "несколько" хранилищь). Нет, это не имеет ничего общего с репликацией или кластеризацией.
Почитайте о git: http://git.or.cz/


>>> Поскольку можно вносить изменения не обращаясь к центральному хранилищу, повышается вероятность что внесенные изменения никто не просмотрит и ухудшится качество кода.
>> непонятно что имеется в виду, потому что предложение бред, может не так перевели с en.
>
>Всё довольно просто: Один из разработчиков вносит изменения в свою локальную копию
>проекта. Потом эти изменения рассылаются остальным участникам проекта. Чем больше хранилищ
>и чем протяжёнее граф синхронизации, тем больше вероятность, что одни разработчики
>работают с новой версией программы, а до других изменения ещё не
>дошли.

описанная вами ситуация не просто нормальна, она повседневна и естественна.
Я пишу свою экспериментальную фичу, которая нафик не нужна 95% разработчиков.
И незачем всем на свете пихать под нос мои соискания. Кто хочет - тот сам возьмет, посмотрит и будет держать себя вкурсе относительно моих разработок.


>>> Провоцирующая легкость создания новой ветви проекта.
>> и?
>
>И плохо!

В мире мало строго черного и строго белого (кроме маздая, он - чистое зло :D  )
Итак, рассмотрим пример системы git, с помощью которой контролируется развитие ядра Линукс.
На git.kernel.org (всего-лишь там, для начала) уже существуют сотни веток Линуха.

В одной ветке ведется развитие одной подсистемы, в другой - другой и т.д. и т.п.

Все вменяемые новинки гогласно определенной политике собираются Торвальдсом и комиттятся в его ветку, которая уже собой представляет тот Линух, который выкладывают на kernel.org в виде тарболов.

Захотелось вам KGDB (ядерный дебаггер) "вне очереди", ну, пока там 2.6.26 еще не вышла.
Пошли, добавили удаленный репозитарий в множество следимых себе в репозиторий и хоть раз в 5 минут собираете оттуда изменения (если они там появляются). И у вас обычное 2.6.24.x,
но с KGDB, причем очень даже up2date. Торвальдс же ("основная" ветка к этому Kgdb лишь только подходит).

Так ли все плохо? ;)

>>> Децентрализованная модель не соответствует современной модели коммерческой разработки ПО.
>> тоже непонятно.
>
>Перевожу: коммерческие разработчики привыкли пользоваться централизованным хранением и
> не привыкли пользоваться распределённым хранением.

Согласен с каждым словом. Кроме того, это касается и некоммерческих разработчиков, которым ломы что-то радикально менять в своей системе контроля версий.

Собсно, задуматься лишь над фактом появления самой новости.
Если бы все было так шоколадно при централизованной разработке - то и новости бы не было ;)
а распределенные системы умерли не родившись (git, mercurial...).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Децентрализованное будущее Subversion"  
Сообщение от Andrew Kolchoogin on 04-Май-08, 10:04 
>> Поскольку можно вносить изменения не обращаясь к центральному хранилищу,
>> повышается вероятность что внесенные изменения никто не просмотрит,
>> и ухудшится качество кода.
> непонятно что имеется в виду, потому что предложение бред, может не так
> перевели с en.

Имеется в виду следующее: наличие централизованного хранилища накладывает на процесс разработки свой отпечаток, выражающийся в том, что изменения надо коммитить часто и мелкими кусками (ну, если, конечно, нет желания получить по шляпе от руководителя проекта за два рабочих дня, впустую потраченных на устранение конфликтов :), и эти мелкие куски сразу видны всем. Соответственно, довольно просто делать cross-auditing кода, когда другие девелоперы видят недоработки или "тупые баги" (опечатки, etc.) друг друга.
Отсутствие централизованного хранилища, собственно, и придумано было для того, чтобы так НЕ делать: обмениваться уже довольно здоровыми патчами (иначе все преимущества распределенного хранения репозитария будут сведены на "нет"). Но такие патчи не так уж и просто просмотреть глазами на предмет аудита -- они большие, затрагивают много файлов, функционал далеко не очевиден, и так далее, и тому подобное.
А то, что отсутствие cross-auditing'а ухудшает качество кода, надеюсь, очевидно всем, кто написал что бы то ни было сложнее, чем "Hello, World!" :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Децентрализованное будущее Subversion"  
Сообщение от Nick email(??) on 04-Май-08, 13:36 
все хорошо в вашей точке зрения окромя одной маленькой вещи.
Вы приравняли децентрализованный метод разработки и большие коммиты, а следом и более никзое качество кода.
А это и нелогично и неправильно.

Нелогично.
Даже самому разработчику проще разбиратся в маленьких коммитах, чем в простынях.

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

Аудит.
Всем подряд разработчикам просто делать нечего как заниматься аудитом друг друга.
Ессьно, это касается лишь свободных разработчиков. Политики организаций этот вопрос могут решать по-своему.
Так вот: мне хочеться писать свои вещи, а вы предлагаете вместо этого заниматься аудитом?
Вобщем, спутаны 2 вещи: разработка и аудит.

Для примера взгляните сюда:
http://git.kernel.org/?p=linux/kernel/git/viro/audit-current...

человек ведет ветку с целью аудита кода некоторых подсистем.
Все. Он берет в эту ветку лишь исследуемый код и все.
Остальное все может быть вообще полным г-ном. Смысл его подвергать аудиту если даже идея хромает? И хромоту идеи нужно обсуждать тоже централизованно если имеет место единое хранилище. А это может быть и тормозом прогресса...

Вон посмотрите лишь на новость пару дней отроду об Pidgin'е. ВАУ-ВАУ! Форк! Ухты!
Да в распределенной системе об этом никто б не стал спорить. Повел я свою ветку, выложил у себя на сайте и до свидания.
Практически невозможно писать абсолютно правильно и рационально одну версию одного проекта. Кто авторитетно заявит, что выбранный путь - ТРУъ? А заявит человек. А раз человек - значит может быть неправ...

Собственно, Линукс своими темпами роста отчасти обязан правильно выбранной системе управления исходным кодом. Никто никому не указ. Каждый пиши что хочешь в своем домашнем репозитории :) А Торвальдс лишь собирает тот код в ваниллу, который считает нужным.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Децентрализованное будущее Subversion"  
Сообщение от fi (ok) on 04-Май-08, 17:12 
>Нелогично.
>Даже самому разработчику проще разбиратся в маленьких коммитах, чем в простынях.

Вы не подумав написали? или просто не работаете в этой области?
Простыня состоит из небольших коммитов в свой репозитарий, а затем мержить то все равно нужно.

>Аудит.
>Всем подряд разработчикам просто делать нечего как заниматься аудитом друг друга.
>Ессьно, это касается лишь свободных разработчиков. Политики организаций этот вопрос могут решать
>по-своему.
>Так вот: мне хочеться писать свои вещи, а вы предлагаете вместо этого
>заниматься аудитом?

Прежде чем сделать ci я всегда проверю на предмет, что поменялась в моей ветке без меня (сделаю diff и если нужно, затем сделаю up). Зачастую, я делаю проверки чаще чем коммиты.  Естественно, я вижу многие вещи, нахожу ошибки (что недавно и произошло). В случаи децентрализованного хранилища, это затруднительно, т.к. изменения накапливаются в другом хранилище.  А мержить один и тот же код всегда проблема.

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "Децентрализованное будущее Subversion"  
Сообщение от Nick email(??) on 04-Май-08, 23:45 
>>Нелогично.
>>Даже самому разработчику проще разбиратся в маленьких коммитах, чем в простынях.
>
>Простыня состоит из небольших коммитов в свой репозитарий

ну а я что написал?? Мсье на читает написанное?

Или простыня - это просто много коммитов? Ну тогда давайте объявим всех продуктивных комиттеров проблемой номер один.


>Прежде чем сделать ci я всегда проверю на предмет, что поменялась в
>моей ветке без меня (сделаю diff и если нужно, затем сделаю
>up). Зачастую, я делаю проверки чаще чем коммиты.  Естественно, я
>вижу многие вещи, нахожу ошибки (что недавно и произошло). В случаи
>децентрализованного хранилища, это затруднительно, т.к. изменения накапливаются в другом хранилище.

а т.к. другое хранилище "далеко" и его проверять так же часто как "своё" "практически невожможно" (ну как, оно ж децентрализованное! как же его можно раз в 5 минут проверять??)
то ессьно весьма затруднительно просмотреть то, что туда кто-то закоммитил.

Самому то не смешно?


>А мержить один и тот же код всегда проблема.

э...  не понял...
а зачем его один и тот же мержить по 10 раз?


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

Ясно, вы даже не представляете как и что с чем связано в репозитории git ядра.
Но это не проблема.Практически любые заблуждения можно выровнять.

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


>В принципе, и сейчас в svn можно смешивать код из разный веток,
>но я не в курсе, чтобы можно было из разных хранилищ,
>может это имеется в виду.

воо... а вот с этого места поподробнее...

Хотел я как-то в gimp внести пару изменений своих...
Ну что "svn co..." edit-edit-edit, "ci" ессьно никак...
И что я делаю дальше?
Есьно, я делаю "cp -a gimp_orig gimp_my", херю разложенный в каждой дире ".svn" диры,
инициализирую заново svn репозиторий и коммичу изменения уже туда.
Трекинг обновлений в основной ветке требует использования утили "patch" и помнить
какой последний коммит из главного в свой репозиторий я сделал...

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

А щас и вовсе знаю, что весь SVN репозитарий можно просто импортнуть в GIT репозитарий,
который обеспечит удобные коммиты МОЕГО кода МНЕ на комп _и_ такой же беспроблемный _теркинг_ оригинального gimp'a.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "Децентрализованное будущее Subversion"  
Сообщение от Andrew Kolchoogin on 05-Май-08, 10:04 
> все хорошо в вашей точке зрения окромя одной маленькой вещи.
> Вы приравняли децентрализованный метод разработки и большие коммиты,
> а следом и более никзое качество кода.
> А это и нелогично и неправильно.

    Я не приравнял.

    Дело в том, что есть некая непреложная истина: _релиз_ собирается _одним_ человеком из _одного_ репозитария. Собственно, можно, например, набрать "tar cvf" "в четыре руки", только вот зачем?

    И этот репозитарий этого самого человека получается в результате наложения патчей, присылаемых ему разработчиками. Если эти патчи будут маленькими, тогда смысл децентрализованных SCM'ов теряется напрочь: они придуманы были _именно_ потому, что для работы, к примеру, Subversion'а необходима постоянная Internet Connectivity с центральным сервером, а для работы, к примеру, Mercurial'а достаточно раз в неделю посещать Интернет-кафе.

    Это очевидно? Очевидно, почему патчи при использовании децентрализованных SCM'ов будут большими?

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

    А он СЕБЕ в репозитарий и будет коммитить маленькими кусками. :) Только из его репозитария релизы не строятся. :)

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

    Это неверно. Неделя маленьких коммитов -- в результате простыня.

> Аудит.
> Всем подряд разработчикам просто делать нечего как заниматься аудитом друг друга.

    Хм. Ник, ты что?-) Ты никогда ничего не разрабатывал, что ли?-)

    _Любой_ разработчик, если он работает над проектом сложнее, чем "Hello, World!", _обязательно_ будет заниматься аудитом чужих коммитов, дабы просто убедиться, что не поломали API, которыми он пользуется. :)))

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

    Да, бесспорно.

> Так вот: мне хочеться писать свои вещи, а вы предлагаете вместо этого
> заниматься аудитом?
> Вобщем, спутаны 2 вещи: разработка и аудит.

    Кросс-аудит -- это НЕОТЪЕМЛЕМАЯ ЧАСТЬ разработки. Попробуй догадаться, зачем существует cvs-src@freebsd.org -- для того, чтобы флудить в Интернете, что ли?-)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "Децентрализованное будущее Subversion"  
Сообщение от Nick email(??) on 05-Май-08, 10:31 
вобщем "большое" и "малекое" - не технический спор.

И вообще, у каждого свое мнение.

Польза/вред децентрализованных репозиториев от этого не изменяется.


Но сама факт сабжа говорит об их правильности. Иначе SVN и не дергался бы.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Децентрализованное будущее Subversion"  
Сообщение от Geol on 04-Май-08, 09:57 
Ну вообщето Коллинз-Сассман не говорил об уходе от централизованной модели. А вот как задумана частичная децентрализация, я не совсем понял. Опять же, реплика Дмитрий Ю. Карпова педставляется довольно разумной, что подозрительно - данный персонаж обычно какую-нибудь теоретизированную пургу несёт...
Вобщем подскажет кто нибудь, где можно почитать об упешном опыте внедрения и применения децентрализованых систем контроля версий?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Децентрализованное будущее Subversion"  
Сообщение от Andrew Kolchoogin on 04-Май-08, 10:05 
> Вобщем подскажет кто нибудь, где можно почитать об упешном опыте внедрения и
> применения децентрализованых систем контроля версий?

Разработка Linux Kernel?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Децентрализованное будущее Subversion"  
Сообщение от Nick email(??) on 04-Май-08, 13:56 
>Ну вообщето Коллинз-Сассман не говорил об уходе от централизованной модели. А вот
>как задумана частичная децентрализация, я не совсем понял. Опять же, реплика
>Дмитрий Ю. Карпова педставляется довольно разумной, что подозрительно - данный персонаж
>обычно какую-нибудь теоретизированную пургу несёт...

Вряд ли подозрительно :)
В данном треде его мнение не такое уж бесспорное.


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

Да, Андрей правильно вот говорит.
Кроме Линуха сво больше проектов на sf.net используют git.
Как то ceph, nilfs...

Я вот Гентушник и заметил тенденцию (всего-ли за последние полгода, ну или 3/4) перехода
оверлеев с SVN на Git.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Децентрализованное будущее Subversion"  
Сообщение от Аноним (??) on 04-Май-08, 14:59 
>>Вобщем подскажет кто нибудь, где можно почитать об упешном опыте внедрения и
>>применения децентрализованых систем контроля версий?
>
>Да, Андрей правильно вот говорит.
>Кроме Линуха сво больше проектов на sf.net используют git.
>Как то ceph, nilfs...

Еще mozilla, Xorg...

В моей конторе Linux отдел естественно тоже :)

>Я вот Гентушник и заметил тенденцию (всего-ли за последние полгода, ну или
>3/4) перехода
>оверлеев с SVN на Git.

:) вот еесли б "emerge --sync" через git pull работал было б вообще зашибись :)
(Еще один "Я вот Гентушник")

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "Децентрализованное будущее Subversion"  
Сообщение от Nick email(??) on 04-Май-08, 15:10 
>Еще mozilla, Xorg...

да, распределенные.
Но Мозиловцы на Меркурии обитают.

>:) вот еесли б "emerge --sync" через git pull работал было б
>вообще зашибись :)

не совсем ;)
rsync здесь как раз по месту. История всия портов среднему гентушнику ни к чему.
А git - это именно постоянное увеличение репозитория...  Не очень гут... совсем не гут в общем случае.

А разработчики, ессьно, порты в репозитории держат.


>(Еще один "Я вот Гентушник")

:)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Децентрализованное будущее Subversion"  
Сообщение от Аноним (??) on 04-Май-08, 15:09 
>А вот как задумана частичная децентрализация, я не совсем понял.

Локальные коммиты. То есть в случае оффлайновости, создается временная ветка local, куда и коммитится. При онлайне, локальная метка вмердживается в основную.

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

Почитать можно в списке проектов, использующих соответствующие системы контроля версий: bzr, git, mercurial... Особенно разные svn vs bzr и прочие.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру