метаданные для подпроектов в хранилище svn

Question

По сути, я ищу способ более легкого поиска вещей в большом / сложном SVN-хранилище.

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

Кто-нибудь много использовал с метаданными в хранилище SVN? Что сработало, а что нет?

Я говорю не только о том, как хранить метаданные, но и о том, что вы делаете с ними, например, о создании индекса HTML. Для хранения, на мой взгляд, есть 3 основных варианта:

1. поместите ваши метаданные в простой файл, который проверяется в репозитории svn. (например, некоторый xml-файл со специальным соглашением о файле, например, svn-metadata.xml). но это делает его независимым от SVN.

2. использовать свойства svn для хранения метаданных. (работает нормально и имеет версии, но затем вы привязаны к svn. Плюс в том, что вы можете привязывать метаданные конкретно к отдельным файлам.)

3. хранить метаданные во внешнем местоположении , например, в базе данных или вики. (более непосредственно интегрируется с функциями хранилища, но не поддерживается версиями и привязан к хранилищам такого типа.)

Я думаю о том, что возможно использовать RDF + RSS в качестве метаданных в виде простого файла, а затем написать что-то, что периодически сканирует репозитории SVN на наличие метаданных, индексирует их в базе данных и создает простое в использовании веб-приложение для облегчить поиск.

Answer 1

На самом деле я бы смешал метаданные в свойствах svn и (версионные) простые xml-подобные файлы.

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

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

2) Сценарии для обработки вашей базы данных будут лучше размещаться в файлах репозитория (в формате xml или в любом другом формате). Типичным примером является сценарий, который компилирует все или часть ваших инструментов и создает инсталлятор, поэтому имеет смысл хранить сведения о ваших инструментах в легко читаемом / управляемом файле. И, как вы указали, он должен быть максимально независимым от сервера (однако у вас может быть несколько ссылок, например, включение ревизии в окончательное приложение для отслеживания их версий).

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

Я просто еще не уверен, какой лучший язык будет для реализации хуков. Python (с pysvn ) великолепен, но каждый раз вызывает перезагрузку интерпретатора и динамически печатается - не проверял влияние. Я не смог найти ни одного надежного API для C #, который бы также работал на Linux с Mono, может быть, C или C ++. Я полагаю, это в основном зависит от того, что должно быть сделано.