SVN и общие папки для разных сайтов

[Dl]

SVN и общие папки для разных сайтов

Добрый вечер!

Возникла такая ситуация:
Есть два сайта, site1 и site2, они используют одну базу данных, вследствие чего у них одна админка на двоих, но с различающимся поведением.
Примерная структура каталогов такая:

site1
- admin
- - core
- - site1_core
- - site2_core

site2
- ~admin
- - core
- - site1_core
- - site2_core

Можно как-то организовать структуру хранилища в SVN, чтобы там лежали только "сайтозависимые" папки?
То есть что-то вроде такого:

site1/trunc
- admin
- - site1_core

site2/trunc
- admin
- - site2_core

В документации есть пункт про externals, но как я понял, это не то.
Может кто сталкивался, буду благодарен.

 

[Wicked]

В документации есть пункт про externals, но как я понял, это не то.

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

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

trunk

 

[Sad Spirit]

Автор оригинала: Dl
В документации есть пункт про externals, но как я понял, это не то.

Это не то, это для подключения кода из внешних репозиториев.

Внутри своего репозитория проще вынести общую функциональность в отдельный модуль, а потом копировать этот модуль внутрь модуля каждого из сайтов. Копирование в SVN --- дешёвая операция.

 

[Wicked]

Это не то, это для подключения кода из внешних репозиториев.

а теперь расскажи, откуда в svn 1.5 взялось это:

Subversion 1.5 takes a huge step in relieving these frustrations. As mentioned earlier, the URLs used in the new externals definition format can be relative, and Subversion provides syntax magic for specifying multiple flavors of URL relativity.

../ Relative to the URL of the directory on which the svn:externals property is set
^/ Relative to the root of the repository in which the svn:externals property is versioned
// Relative to the scheme of the URL of the directory on which the svn:externals property is set
/ Relative to the root URL of the server on which the svn:externals property is versioned

 

[Sad Spirit]

Ну да, облегчили процесс выстрела себе в ногу, при этом:

Perhaps most disappointingly, the working copies created via the externals definition support are still disconnected from the primary working copy (on whose versioned directories the svn:externals property was actually set). And Subversion still truly operates only on nondisjoint working copies. So, for example, if you want to commit changes that you've made in one or more of those external working copies, you must run svn commit explicitly on those working copies—committing on the primary working copy will not recurse into any external ones.

 

[MiksIr]

А еще, если я не ошибаюсь, external привязывается жестко к определенной ревизии? Или умеет к HEAD привязываться, дабы на каждом чекауте бралась голова external ветки?

 

[Sad Spirit]

Автор оригинала: MiksIr
Или умеет к HEAD привязываться, дабы на каждом чекауте бралась голова external ветки?

Умеет, но в документации, куски из которой цитировались выше, как раз рекомендуется привязываться к конкретной ревизии.

 

[MiksIr]

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

 

[Dovg]

Красиво

+1

больше хлопот, чем удобства

А в чем хлопоты?

 

[MiksIr]

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

С другой стороны, у нас, например, есть несколько модулей и шаренные библиотеки. Если я начну делать для каждого модуля сборки "модуль+библиотека" - может получится, что в продакшене получится у каждого модуля своя копия щаренных библиотек - что не очень правильно. Так что мне удобнее отдельно делать сборки для модулей и для библиотеки, отдельно их выкатывать. А за нарушениями API следить при разработке.

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

 

[Dl]

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

 

[wIliaM]

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

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

 

[Dl]

Спасибо!
Вроде поборол, но без помощи "напильника" не обошлось

 

[Wicked]

wIliaM
спасибо, интересный подход к экстерналам в бранчах.
только в моем случае это будет не piston, а как раз svnmerge.py