Установка производилась на виндовом 2k3 серванте с первым сервиспаком, однако предположу что данное руководство применимо ко всем операционным системам семейства Win NT.

Итак, сходил на официальный сайт  и скачал на момент написания данной статьи последнюю версию Subversion.

Инсталляция сервера

Запусктил инсталяционный файл и в процессе инсталляции указал установочную директорию (D:\SVN\Subversion).

Итак файлики успешно распаковались и готовы к использованию.

Создание репозитория SVN

Далее выполнив эту команду:

>svnadmin create D:\svn\Repository

создал репозиторий, где будут располагаться файлы базы данных, конфигурации SVN.

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

>sc create SVN binPath= "d:\SVN\Subversion\bin\svnserve.exe --service --root d:/SVN/Repository"
DisplayName= "Subversion Repository" depend= "Tcpip" start= auto

данной командой создается сервис с именем SVN, который будет автоматически при старте операционной системы запускать наш SVN-сервер.

Откровенно отмечу, что на этом шаге мне пришлось несколько повозиться:

Во-первых, обратите внимание, на пробелы в параметрах команды SC.exe. Оказываются они обязательны.

Во-вторых, будьте внимательнее с пробелами в пути к svnserve.exe и/или репозитария (параметр binPath). Если таковые имеются, то путь(и) необходимо помещать в дополнительные кавычки обрамляя слэшем, вот так

>sc create <name> binPath= "\"C:\Program Files\Subversion\bin\svnserve.exe\" ..."

Конфигурация прав доступа

Лезу в директорию репозитория D:\svn\Repository в каталог conf. Открываю файл svnserve.conf и в секции [general] разкомментировал следующие параметры:

anon-access = read
auth-access = write
password-db = passwd

Далее залез в файл passwd и добавил свой логин и пароль, с которым я буду коннектиться к серверу.

Запуск сервера

net start SVN

Жду когда сервис запустится и проверяю командой

svn info svn://localhost

успешный старт SVN-сервера. На консоль выведется примерно следующее:

Path: localhostURL: svn://localhost
Repository Root: svn://localhost
Repository UUID: c422f63f-1457-454e-a783-90e2cfd0cfb5
Revision: 0
Node Kind: directory
Last Changed Rev: 0
Last Changed Date: 2008-03-14 00:11:02 +0200 (Пт, 14 мар 2008)

По идее установка самого сервера закончена, и его уже можно использовать. Помещение, выгрузку исходников, коммит, апдэйт, контроль ревизий файлов, и т.д. можно осуществлять посредством того же консольного клинета svn, входящего в поставку вместе с самим сервером. Однако для более удобного пользования системой, можно посоветовать виндюшный SVN-клиент – черепашку TortoiseSVN. Программа встраивается в контектсные менюшки операционной системы и позволяет практически в любом месте и в любом файловом менеджере работать с SVN.

Пример экспорта ddl-схемы на основе *.hbm.xml - маппинг-файлов:

<target name="ddl.generate">
	<path id="hibernate.export.classpath">
		<fileset dir="lib/">
			<include name="*.jar" />
		</fileset>
	</path>
	<taskdef name="schemaexport" classname="org.hibernate.tool.hbm2ddl.SchemaExportTask"
		classpathref="hibernate.export.classpath" mce_href="hibernate.export.classpath" />
	<schemaexport properties="../hibernate.properties" text="yes" drop="no" delimiter=";" output="ddl-schema.sql">
		<fileset dir="${hibernate.mapping.dir}">
			<include name="**/*.hbm.xml"/>
		</fileset>
	</schemaexport>
</target>

Взяв на вооружение Hibernate Annotations, задался целью добиться аналогичного результата. Решением явилось использование класса org.hibernate.tool.ant.HibernateToolTask из библиотеки hibernate-tools.jar.

Вот пример экспорта ddl-схемы на основе аннотированных классов, находящихся в папке ${targetdir}:

<target name="ddl.generate">
	<path id="hibernate.export.classpath">
		<fileset dir="lib/">
			<include name="*.jar" />
		</fileset>
	</path>
	<taskdef name="hibernatetool" classname="org.hibernate.tool.ant.HibernateToolTask"
		classpathref="hibernate.export.classpath" mce_href="hibernate.export.classpath" />
	<hibernatetool destdir="${targetdir}">
		<classpath>
			<path location="${targetdir}" />
		</classpath>
		<annotationconfiguration configurationfile="bin/hibernate.cfg.xml" />
		<hbm2ddl export="true" create="true" delimiter=";" format="true" outputfilename="ddl-schema.sql" />
	</hibernatetool>
</target>

Для поиска данного решения помогли следующие ссылки:

• http://www.hibernate.org/hib_docs/tools/reference/en/html/ant.html
• http://www.goodidea.ru/static/a5720.jsp

Объекты реляционной базы данных будут рассматриваться в контексте реляционной СУБД Oracle. Такой подход принят потому, что проектирование физической модели реляционной базы данных в основном выполняется для конкретной среды ее реализации.

В Oracle термин схема (Schema) используется для описания всех объектов базы данных, которые созданы некоторым пользователем. Для каждого нового пользователя автоматически создается новая схема.

Для создания таблиц и представлений наличие схемы не обязательно. Если у вас планируется инсталляция только одной логической базы данных, то ясно, что можно обойтись и без схемы. Но если планируется, что одна и та же СУБД будет использоваться для поддержки нескольких баз данных, то надлежащая организация объектов баз данных в схемы может значительно облегчить сопровождение этих баз данных. На практике схема часто ассоциируется с объектами определенного пользователя физической базы данных.

Помимо схемы, не обязательными элементами программной среды реляционных баз данных являются кластеры и каталоги.

Кластер (Cluster) - это объект, задающий способ совместного хранения данных в нескольких или одной таблице. Данный объект представляет собой группу каталогов, к которым можно обращаться через одно соединение с сервером базы данных (программная компонента СУБД). Одним из критериев использования кластера является наличие общих ключевых полей в нескольких таблицах, которые используются в одной и той же команде SQL. Обычно кластеризованные столбцы или таблицы хранятся в базе данных в виде таблиц хэширования (т.е. специальным образом).

На практике процедура создания каталога определяется реализацией СУБД на конкретной операционной платформе. Под каталогом понимается группа схем. На практике каталог часто ассоциируется с физической базой данных как набором физических файлов операционной системы, которые идентифицируются ее именем.

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

К числу основных объектов реляционных баз данных относятся таблица, представление и пользователь.

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

Представление (View) - это поименованная динамически поддерживаемая СУБД выборка из одной или нескольких таблиц базы данных. Оператор выборки ограничивает видимые пользователем данные. Обычно СУБД гарантирует актуальность представления - его формирование производится каждый раз, когда представление используется. Иногда представления называют виртуальными таблицами.

Пользователь (User) - это объект, обладающий возможностью создавать или использовать другие объекты базы данных и запрашивать выполнение функций СУБД, таких как организация сеанса работы, изменение состояние базы данных и т. д.

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

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

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

Определенные пользователем типы данных (User-defined data types) представляют собой определенные пользователем типы атрибутов (домены), которые отличаются от поддерживаемых (встроенных) СУБД типов. Они определяются на основе встроенных типов. Определенные пользователем типы данных образуют ту часть среды СУБД, которая организована в соответствии с объектно-ориентированной парадигмой.

Для обеспечения эффективного доступа к данным в реляционных СУБД поддерживаются ряд других объектов: индекс, табличная область, секция.

Индекс (Index) - это объект базы данных, создаваемый для повышения производительности выборки данных и контроля уникальности первичного ключа (если он задан для таблицы). Полностью индексные таблицы (index-organized tables) исполняют роль таблицы и индекса одновременно.

Табличное пространство или область (Tablespace) - это именованная часть базы данных, используемая для распределения памяти для таблиц и индексов. В Oracle 9i - это логическое имя физических файлов операционной системы. Все объекты базы данных, в которых хранятся данные, соответствуют некоторым табличным пространствам. Большинство объектов базы данных, в которых данные не хранятся, находятся в словаре данных, расположенном в табличном пространстве SYSTEM.

Секция (Partition) - это объект базы данных, который позволяет представить объект с данными в виде совокупности подобъектов, отнесенных к различным табличным пространствам. Таким образом, секционирование позволяет распределять очень большие таблицы на нескольких жестких дисках.

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

Данные объекты реляционной базы данных представляют собой программы, т.е. исполняемый код. Этого код обычно называют серверным кодом (server-side code), поскольку он выполняется компьютером, на котором установлено ядро реляционной СУБД. Планирование и разработка такого кода является одной из задач проектировщика реляционной базы данных.

Хранимая процедура (Stored procedure) - это объект базы данных, представляющий поименованный набор команд SQL и/или операторов специализированных языков обработки программирования базы данных (например, SQLWindows или PL/SQL).

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

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

Триггер (Trigger) - это объект базы данных, который представляет собой специальную хранимую процедуру. Эта процедура запускается автоматически, когда происходит связанное с триггером событие (например, до вставки строки в таблицу).

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

Пакет (Package) - это объект базы данных, который состоит из поименованного структурированного набора переменных, процедур и функций.

В распределенных реляционных СУБД имеются специальные объекты: снимок и связь базы данных.

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

Связь базы данных (Database Link) или связь с удаленной базой данных - это объект базы данных, который позволяет обратиться к объектам удаленной базы данных. Имя связи базы данных, грубо говоря, можно представить как ссылку на параметры доступа к удаленной базы данных.

Для эффективного управления разграничением доступа к данным в Oracle поддерживает объект роль.

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

Неочевидный баг обнаружил коллега по работе в одном из самых популярных смотрелок гипертекстовых страниц всех времен и народов. Неочевидный – потому что, баг проявляет себя непосредственно при условии использования виндовых тем (стилей оформления окошек в Windows XP) .

Так вот, при размещении на форме кнопки с длинным названием у ослика явно наблюдаются проблемы с масштабированием границ этой кнопки.

То есть, при отображении следующей конструкции:

<input type="button" value="Регистрация обращения" />
<input type="button" value="Регистрация" />

Получаем вот такой результат:

Методом эмпирических экспериментов было выявлено, что MS IE безжалостно уродует кнопку, размер которой больше чем 40х159 пикселей.

Баг замечен как в 6-ой, так и 7-ой версии MS IE. Чем руководствовались разработчики популярного браузера, ограничивая размеры элемента этими магическими числами? Науке и мне не известно.
Интересен и тот факт, что и Opera и FireFox при тех же условиях отображают кнопки нормально, без каких либо недоразумений. Хотя в общем-то ничего удивительного.

Так что, господа дизигнеры, бдите и аккуратней при обзывании батонов
.

Давно где-то лет восемь так назад, когда Я и Интернет был не таким большим как сейчас, когда не существовало ни ЖэЖистов, ни блоггеров и блоггинга как такового. Так вот, отлично помню. Второй курс универа. Зима. Вечер. После очередной халявной вылазки в Инет, под видом прилежного студента, занимающимся, исключительно, курсовым проектом, возвращаюсь с учебного корпуса в общагу. Наблюдаю как в лучах фонарей, снег неспешно валит с сумеречной пустоты темного зимнего неба. И в это время ловлю мысль о том, что круто и классно было бы в этом самом Интернете завести свой электронный дневник. Дневник в качестве сетевого ресурса, на котором можно было бы опубликовывать свои мысли, взгляды, размышления. Как именно это сделать, тогда я понятия даже не имел, однако привлекла сама оригинальность и первобытность идеи, которая так ярко вспыхнула, и также стремительно погасла тем зимним вечером прошлого тысячелетия.

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

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

Так что, господа блоггеры. Хех! Как ни крути, но я первый придумал блоггинг … и всё тут

Хэлло ворлд.

Ура! Я наконец-то завел свой блог, а это мой первый пост.

Тест. Траливали.

Как ещё мы начинаем свои блоги, дневники, живые журналы?

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

Никакие это не рекомендации типа: «Какие должны быть первые посты?» Ничуть. Здесь каждый выбирает сам. Как пел классик: «Хочешь - можешь быть Буденным, хочешь - лошадью его». Благо нынче каждый блоговод, если конечно постарается, найдет своего читателя, соратника и оппонента. В этом и главная прелесть Интернета и блогосферы в частности. Объединение людей по общим признакам.

Ещё в первых постах в основном принято определять цели и мотивы, побуждающие заведение электродневника. Ну что ж раз принято, - надо определиться. Какие у меня цели? Поднимать в месяц с блога 10000$, ничего не делать и наслаждаться жизнью : ) гы. Да, хороша цель, однако ничего не делать, скорее всего, не получиться, да и скучно это – ничегонеделание.

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

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

Так что, это мой первый пост! И добро пожаловать на мой персональный блог.