2012-01-12 4 views
0

Я был в этой задаче в течение нескольких дней и не смог ее решить.Выборочный экспорт файлов SVN в репозиторий

Я не уверен, если мой метод является возможным, так что если кто-нибудь имеет лучший обходной путь я открыт для идей, поэтому я собираюсь предложить всю картину

Это сценарий

У нас есть большой репозиторий, который мы сейчас переходим из StarTeam в SVN.

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

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

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

Благодаря

ответ

0

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

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

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

+0

Спасибо за быстрый ответ. Мне не нужна история версий. Я просто должен быть в состоянии вытащить этот пакет с частицами каждый раз, когда у нас будет новая версия. В starTeam есть функция иметь связанные файлы, которые в основном означают, что у меня один и тот же файл в двух местах, но когда один из них обновляется, я могу определить, что он изменился, посмотрев на его ссылку. К сожалению, репозиторий репозитория не является вариантом – Jonxm05

+0

Похож на svn: externals также могут делать файлы. StackOverflow: [возможно ли связывать файлы репозитория SVN ...] (http://stackoverflow.com/questions/1401951/is-it-possible-to-link-svn-repository-files-so-that-a- file-is-a-a-referen) и [svn: externals] (http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html). – joneskoo

+0

Возможно, вы сможете использовать свойства svn (например, внешние, но другие), чтобы пометить файлы, которые вы хотите экспортировать, и заставить инструмент экспортировать файлы на основе этой информации. Я не знаю, есть ли готовые решения. – joneskoo

0

Это не решение на основе SVN, а обходное решение для вашей проблемы на основе ограничений SVN.

Не уверен, что это сработает, но вы можете подумать об изменении макета своего репо, просто изменив направление ссылок на файл перевода. Вы можете хранить фактические файлы в своем справочнике, скажем, тот, который хотите экспортировать, и использовать ссылки, в которых ранее находились фактические файлы («, распределенные по остальной части дерева проекта»).

Там у вас не возникнет проблем с SVN для экспорта каталога файлов переводов.

0

Не совсем уверен, что вы подразумеваете под Ссылки. Subversion в Unix может хранить символические ссылки на другие файлы в репозитории, но я обычно не рекомендую его. Это не Windows.

Как вы используете эти ссылки точно? Вы экспортируете только этот каталог, и поскольку он связан с фактическим контентом, вы вытаскиваете только нужные файлы? Являются ли они похожими на ссылки файловой системы, или это проприетарная функция StarTeam, например, старый share в VisualSourceSafe?

Обычно я рекомендую позаботиться о чем-то подобном с помощью какой-либо системы сборки. Вы можете использовать язык сборки, такой как Ant, который достаточно мощный и работает на любой платформе, использующей Java. Или вы можете использовать что-то вроде Python или Perl. Я бы держался подальше от сценариев оболочки и скриптов Batch, так как они не совсем универсальны.

Вы делаете полную проверку из своего репозитория, а затем запустите сборку для экспорта. Экспорт просто скопирует нужные файлы в какой-либо каталог сборки. (Я рекомендую создать каталог под именем target под корнем проверки и поместить туда все сгенерированные файлы. Он очень быстро очищает сборку. Я бы поставил сгенерированную сборку под номером target/archive).

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

Смежные вопросы