Структура svn репозитория,где хранить продакшн версию сайта. Помогите определится.

[KhmelevskyY]

Структура svn репозитория,где хранить продакшн версию сайта. Помогите определится.

Здравствуйте. Возможно не по адресу, но не придумал куда написать еще. Вопрос в следующем. Запустил я у себя на сервере Subversion, создал проект, создал три папки trunk, tags и branches, все как рекомендуют разработчики svn. Сама разработка ведется в основной ветке trunk. Но у меня вопрос, у меня есть как development версия проекта, со всеми комментариями phpDoc вставками, так и production врсия, в которых с помощью ант скрипта вырезаються все комментарии, символы табуляция, перевода строки и т.д. Так вот и возник у меня вопрос, а как лучше хранить production версию в репозитории? Как вы решаете эту задачу??

 

[DiMA]

Комменты и табуляция на продакшене никому не мешает, ибо компилится в байт код при первом обращении и дальше живет в кеше.

Резать пробелы нужно с CSS, но это задача не к SVN... Автоматически парсим исходный CSS, результат в кеш и выдаем из кеша файл.

 

[KhmelevskyY]

Забыл добавить. На данный момент, у меня есть такое видение о структуре:
/trunk
--production
--development

Но при таком подходе выйдет что у меня будут расходится версии продакшн с девелопмент после коммитов, и только когда я закончу весь функционал и создам продакшн версию и, например, скопирую их в tags я получу рабочий продакшн собранный на основе девелопмент версии той же ревизии. Затем когда я буду создавать новый продакшн релиз у меня все файлы будут удалены и сгенерированы заново ант-скриптом. Что в этом случае сделает subversion?

Или может лучше продакшн версию хранить в архиве, что неудобно?

-~{}~ 20.07.09 18:05:

Автор оригинала: DiMA
Комменты и табуляция на продакшене никому не мешает, ибо компилится в байт код при первом обращении и дальше живет в кеше.

Резать пробелы нужно с CSS, но это задача не к SVN... Автоматически парсим исходный CSS, результат в кеш и выдаем из кеша файл.

получается не нужно делать никакой отдельной продакшн версии? dev версия и есть продакшн, просто нужно движок сделать так чтобы оно оптимизировало тот же css и т.д.??

ЗЫ. где можно почитать о продакшн в контексте web?

-~{}~ 20.07.09 21:41:

мда, сумбурно получилось...видать нельзя на отдыхе после пива на форуме постить.

Но вопрос все таки остался, постараюсь описать более внятно:
разрабатывается web проект, весь код обильно документирован, каждый класс находится в отдельном файле, что удобно с точки зрения разработке и сопровождения, но не правильно с точки зрения производительности. Поэтому нужно генерировать production версию на основе development, если я не прав поправте меня, или расскажите как поступают у вас. Теперь мне непонятно, стоит ли хранить production версию в svn-репозитории, или хватит только development версии и скрипта, который генерирует production версию? В принципе, хотелось бы, когда создается новый релиз, в subversion сохранялся не только development версия, но и producton, чтобы, если потребуется, можно вытянуть с репозитория готовую production версию любого релиза. Но как это правильно организовать?

 

[fixxxer]

>>разрабатывается web проект, весь код обильно документирован, каждый класс находится в отдельном файле, что удобно с точки зрения разработке и сопровождения, но не правильно с точки зрения производительности

как уже сказал Дима, на продакшене использовать акселераторы

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

для css и js куча готовых компрессоров.

девелопмент версия делается скриптом раскладки. svn export + постобработчик + tar.gz на сервера. держать генерированные файлы в svn это вообще глупость.

ветка "на прод" это глупость.

ветки надо делать на стабильный код (как минимум проходящий все тесты - из него идет раскладка) и девелоперские ветки. обычно до релиза идет разработка в trunk +/- отдельные ветки на крупные переработки по необходимости, впоследствии trunk делается стабильным. либо же делается форк транка в скажем /stable - не суть важно, вопрос соглашений

 

[dimagolov]

но не правильно с точки зрения производительности

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

В принципе, хотелось бы, когда создается новый релиз, в subversion сохранялся не только development версия, но и producton

по идее у тебя должен быть скрипт, который автоматом транслирует development в production. если его нету, то стоит задуматься о его создании, а не хранении production в svn