понедельник, 14 июня 2010 г.

Фотоотчет(63 фото): YAPC-2010 День докладов

63 фотографии с Perl Mova + YAPC-2010 проходившей в Киеве.
ПЕРЕЙТИ В ФОТОАЛЬБОМ>>

ЗЫ: В picasa web-albums тоже можно оставлять комментарии ;)

суббота, 5 июня 2010 г.

Вы не любите котов? Так Вы просто не умеете их готовить.

Многие сейчас переходят с Subversion на Git. Многие считают, что merge в Subversion практически невозможно использовать... и так далее.

Эта статья для тех, кто еще пользуется Subversion, но только планирует перейти на Git.

После прочтения статьи просто взвесьте  все за и против, которые Вы получите при переходе на Git.

Я ни в коей мере не наезжаю на Git, но для меня существует ряд проблем при переходе на новую систему контроля версий:
  1. Перенести весь код с svn-репозитария в git-репозитарий с сохранением всей истории изменений.
  2. Обучить всех сотрудников работе с новой системой контроля версий.
  3. Найти адекватные инструменты для работы с Git под Windows, MacOS, Linux. Например, я использую модуль Subclipse для Eclipse и достойной замены пока не вижу. 
  4. Принять новую схему работы с системой контроля версий. На каждый баг/таск создавать ветку...
  5. Изменить скрипты деплоинга и обновления проекта.
 Все, что требуется от Вас, это оценить стоит ли оно того.

 Готовить Subversion  мы будем в два этапа ( я буду больше рассказывать "как", чем "зачем" ):
  1. Работа со своими ветками
  2. Управление релизами
Сразу замечу, что все что здесь описано, требует Subversion >= 1.6.x :
  1. Умный мердж появился только в subversion 1.5 (До этого, я соглашусь, мерджинг был неадекватный)
  2. Сокращенные пути через "^" появились в subversion 1.6
Допустим у нас есть репозитарий по адресу  http://svn.myrepo.com/
И вся основная разработка ведется в http://svn.myrepo.com/trunk. (Trunk - это ствол (в переводи с англ.))
Все дополнительные ветки будут создаваться в http://svn.myrepo.com/branches/

четверг, 3 июня 2010 г.

Удаление svn:externals для файла

Что такое svn:externals?
Это атрибут, который можно установить любому каталогу в репозитарии. Он позволяет подгружать файлы и каталоги с другого места.
(За деталями сюда - http://svnbook.red-bean.com/en/1.0/ch07s03.html)
До версии subversion-1.6 возможно было указать только ссылки на внешние каталоги. То есть внешний файл было невозможно указать.
С версии 1.6 появилась возможность указывать в svn:externals и отдельные файлы. Но существует несколько особенностей про которые нужно помнить:

  1. Невозможно указать ссылку на файл во внешнем репозитарии( а на каталог возможно ).
  2. Особенная процедура удаления ссылки на внешний файл (поскольку файл добавляется в локальную копию, как любой другой файл с репозитария).

Для удаления ссылки на внешний файл необходимо:

  1. Отредактировать либо удалить аттрибут  svn:externals и сделать коммит.
  2. Удалить папку содержащую внешний файл. Просто удаления файла - недостаточно.
  3. Обновиться для востановления удаленной папки ( "svn up" )
  4. Шаг 2 и 3 необходимо провести каждому пользователю репозитария поскольку "svn up" ничего не даст.

Вся загвоздка в пункте 4. 
Допустим у Вас был внешний файл прописанный через svn:externals, а затем Вы убрали внешнюю ссылку на файл и завели отдельную его копию. Никто и никогда про это не узнает и все будут пользоваться старым файлом пока не выполнят пункт 4.