LINUX.ORG.RU

Небольшой скриптик для небольших проектов в svn


0

0

Дело в том что у нас еть изрядно распухший проект состоящий нынче уже из ~10 подпроектов, и это не предел. Предложение установить билд-сервер пока наткнулось на некие проблемы, в частности мотивации 8). Но не суть важно, суть в том что в svn проекты лежат в таком виде

/mainProj
  /subA
    /trunk
    /branches
      /1.0
  /subB
  /subC
    /trunk
/slaveProj
  /subA
  /subB

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

Задача: выбирать из репозитория все дерево исходников, автоматически определяя есть ли «trunk», и складировать в директорию в виде удобном для дальнейшей сборки одной командой: build.xml и настроен так что, вызвав build он потянет за собой ../subB и ../mainProj/subA - именно это накладывает определенную иерархию директорий.

Решение из двух скриптов:

#--- lib.sh
#!/bin/bash

#list subprojects
# $1 - svn url
listProjects(){
  svn list "$1"
}

#checkout project
# $2 - project url on svn repository
# $3 - local project path
checkoutProject(){
  URL=$1
  for DIR in `svn list  "$URL"`; do
   if [[ "$DIR" == "trunk/" ]]; then
     #project has trunk and branches
     #we need trunk
     URL="${URL}trunk/"
   fi
  done;
  echo "Checkout project at \"$URL\" to \"$2\""
  svn checkout "$URL" "$2"
}

#checkout projects 
# $1 - svn url
# $2 - root dir
# $3 - exceptions (not required)
checkoutProjects(){
  echo "SNV repository url:    $1"
  echo "Working root directoy: $2"
  echo "Exceptions regexp:     $3"
  if [[ ! -d $2 ]]; then 
    mkdir $2
  fi;
  for PROJ in `listProjects "$1"` ; do
    echo "Project $PROJ:"
    if [[ ! -n "$3" || !( "$PROJ" =~ $3 ) ]] ; then
      checkoutProject "$1/$PROJ" "$2/$PROJ"
    else 
      echo "skipped by EXCEPTION regular expression."
    fi;
  done;
}

#-- install.sh --
#!/bin/bash

PROJ_NAME="mainProj"
if [[ ! -n "$SVN_REPO" ]]; then
  SVN_REPO="svn://192.168.1.1"
fi; 
SVN_URL="$SVN_REPO/$PROJ_NAME"
ROOT_DIR="./$PROJ_NAME"
EXCEPT='^(install)/$' #like `^(install|docs)/$` 

include(){
  TEMP_FILE=${1//'/'/'_'}
  svn cat "$1" > "$TEMP_FILE"
  . "$TEMP_FILE"
}

include "$SVN_URL/install/lib.sh"

checkoutProjects "$SVN_URL" "$ROOT_DIR" "$EXCEPT"
install.sh и lib.sh лежат в '/mainProject/install/' - для этого каталога есть правило игнорирования.

Для slaveProject пришется еще один скрип

#!/bin/bash

if [[ ! -n "$SVN_REPO" ]]; then
  SVN_REPO="svn://192.168.1.1"
fi; 

include(){
  TEMP_FILE=${1//'/'/'_'}
  svn cat "$1" > "$TEMP_FILE"
  . "$TEMP_FILE"
}

include "$SVN_REPO/mainProj/install/lib.sh"
include "$SVN_REPO/mainProj/install/install.sh"

PROJ_NAME="SlaveProj"
SVN_URL="$SVN_REPO/slave-proj"
ROOT_DIR="./$PROJ_NAME"
EXCEPT='^(install)/$' #like `^(install|docs)/$` 

checkoutProjects "$SVN_URL" "$ROOT_DIR" "$EXCEPT"

он вытягивает сначала нужные lib.sh а затем mainProject и свой проект, все работает.

Вопрос: как разруливать подобные ситуации без вышеприведенного велосипедостроения?

★★☆

Как же не хватает (клиент|конфиг)спеков в опенсурсных VCS...

Можно попробовать реализовать похожую идею средствами SVN.

vaulter ()
Ответ на: комментарий от linuxfan

Тут еще гимморой со сторонними библиотеками - кои какбы смысла хранить в svn и нету, но с другой стороны они обновляются и обновляется работа с ними, так что по хорошему бы - @345 юзает external-lib-3.4, а HEAD - external-lib-4.1 и шоб это также автоматом скачивалось, автоматическое прикручиваение библиотек к нетбинсовому менеджеру библиотек я уже осилил

wfrr ★★☆ ()
Ответ на: комментарий от tailgunner

хватит :)

По крайней мере это привносит неудобства в тех случаях, когда svn:exports используется не по прямому назначению (не для 3rd parties).

Хотя, куда мне с вами спорить.

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

vaulter ()
Ответ на: комментарий от vaulter

> хватит :)

Я думаю, это можно обойти с помощью хуков, по крайней мере, в Mercurial (там есть похожая фишка - subrepositories).

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Да я вроде саму возможность и не отрицал. В любом случае возни много больше чем с clearcase или perforce.

Будем считать, что я слил :)

vaulter ()
Ответ на: комментарий от vaulter

> Будем считать, что я слил :)

Да я просто интересовался. Сам с CC никогда не работал, о спеках конфигов только слышал, а вырисовывается задача, где нужно что-то похожее.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Посмотри лучше perforce. Та же идея, только сама VCS много проще (ИМХО). Можно даже урезанную версию скачать на посмотреть :)

vaulter ()
Ответ на: комментарий от vaulter

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

По теме. Делаешь отдельные папки на нужные версии билдов. Туда набрасываешь svn:externals.

baverman ★★★ ()

встречные вопросы

1. почему бы не реорганизовать структуру директорий посредством самого svn? то есть, завести везде единообразную структуру и избавиться от излишней сложности в скриптах:

if [[ «$DIR» == «trunk/» ]];

2. почему бы всё-таки не поставить (=продавить) билд-сервер? мой личный опыт показывает, что эта игра стоит свеч. апатичные девелоперы сначала недоумённо спрашивают, зачем он вообще нужен, но затем привыкают

имхо, хаос надо давить, а не прогибаться под него. и это вопрос скорее организационного характера, нежели технического ("велосипедостроение")

Zloddey ()
Ответ на: встречные вопросы от Zloddey

1) там написано «причем так как разработчиков немного то „ответвления“ есть не везде»

2) Уважаемый, это я и сам знаю, однако, пока «выбивается» сервер для стенда, где будет деплоиться проект, есесно, что там захотят другие или нет - но будет развернут «continuous build» ибо стенд должен быть в актуальном состоянии.

wfrr ★★☆ ()
Ответ на: комментарий от wfrr

так как разработчиков немного то «ответвления» есть не везде

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

пока «выбивается» сервер для стенда, где будет деплоиться проект

успехов


install.sh и lib.sh лежат в '/mainProject/install/' - для этого каталога есть правило игнорирования.

это я правильно понял, что в виду имеется svn ignore? ящитаю, скрипты сборки должны тоже лежать под сорс-контролем, чтобы соответствовать актуальной структуре проекта

Zloddey ()
Ответ на: комментарий от Zloddey

>даже если один разработчик пилит один проект, то что мешает ему (при необходимости) сделать бранч?

это git к подобным привычкам приучает, да. ответвил-набыдлокодил-слил-убил

Zloddey ()
Ответ на: комментарий от Zloddey

это я правильно понял, что в виду имеется svn ignore?

Нет 8)

в скрипте есть строки


  if [[ ! -n "$3" || !( "$PROJ" =~ $3 ) ]] ; then #тут проверяется regexp для игнорирования аргумент - $3 
    checkoutProject "$1/$PROJ" "$2/$PROJ" 
  else  
    echo "skipped by EXCEPTION regular expression." 
  fi; 

тем более что я там комментарии перед функциями писал

wfrr ★★☆ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.