Subversion: Начало

Благодаря интуитивно понятному интерфейсу всяких программ и эклипсоплагинов создается впечатление, что знаешь как работать с свн. Но когда дело доходит до суровых консольных условий приходится читать svn book и с плачем гуглить.

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

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

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

svnadmin create /var/svn-repos/content
cd /home/mycontent

Способ 1, не пугающий.

1. svn checkout file:///var/svn-repos/content .
2. svn add ./*
3. svn commit

Да-да, в первом шаге в конце отделенная пробелом точка (если ее не поставить то внутри /home/mycontent получим заверсионеную подпапку content).
Не пугающий, потому что здесь сам процесс помещения контента идет так, как и подсказывает разум. Однако, такой способ доступен только если после шага 0 вы не успели сделать роковой свн импорт (и ваш репозиторий пуст). Если сделали - выбираем способ для смелых.

Способ 2, для смелых.
На самом деле это полностью рабочий и безопасный способ (я его и использовал так как см выше).

1. svn import -m "Initial import" \
         file:///var/svn-repos/content
2. svn checkout --force \
         file:///var/svn-repos/content .

Способ этот для смелых, потому что создается впечатление, что свн перезаписывает все файлы (без параметра --force свн вежливо указывает на наличие файлов с таким же именем как и в репозитории). Однако по авторитетному заявлению в svn help checkout:

If the obstructing path is the same type (file or directory) as the corresponding path in the repository it becomes versioned but its contents are left 'as-is' in the working copy.

Вот так-то.

Wireless Toolkit: чистка записей в store

Вот и подошел к концу весьма интересный (но и столь же бесполезный, как оказалось впоследствии - см дальше) процесс разработки приложений на Java MicroEdition с использованием Sun Java Wireless Toolkit. К счастью в течение основной работы не приходилось заниматься настройкой-колупанием самого тулкита. Но вот сегодня настал и такой час.
Дело в том, что тулкит умеет эмулировать выполнение мидлета. Более того он умеет эмулировать и сохранение данных в record store. Что как раз и вышло боком, когда формат хранящихся данных был изменен. При старте мидлет отчаянно пытался зачитать все, что было сохранено прежде, как следствие - эксепшын.
Выход был очевиден - почистить эмулирующийся record store. Но как? Как ни странно ответ был найден обычным методом тыка без привлечения гугла.
В установленной папке Wireless Toolkit'а имеется папка bin и в этой папке лежит замечательный экзешник - utils.exe. В ней много всяких фич, в том числе и понадобившаяся мне - "Clean database".
Также стоит упомянуть такую фичу как "Sign midlet". Пока не пробовал, но если в мидлете имеются небезопасные операции (отправка сообщения, подключение в инет), то мидлет даже в эмуляторе начинает запрашивать разрешения пользователя. У меня в таких случаях эмулятор просто виснул. Поэтому чтобы избежать неприятных ситуаций лучше в эмуляторе засайнить мидлет.
Как раз с процессом sign'а и связана бесполезность разработанного приложения. Дело в том, что приложение мое использует упомянутые небезопасные операции. И чтобы мидлет при каждой такой операции не запрашивал разрешения пользователя, требуется подписать мидлет по-настоящему. Что это такое и почему это нереально рассказывается здесь.