#c# #sql #svn
#c# #sql #svn
Вопрос:
Моя команда разрабатывает новое приложение (C #, .Net 4), которое включает в себя хранилище для общего пользовательского контента. Нам нужно решить, где его хранить. Требования следующие:
- Делитесь файлами между пользователями.
- Поддерживайте версии.
- Включить поиск по тегам и поддерживать дополнительные запросы, такие как «все файлы, созданные людьми из группы X»
- Разные представления для разных людей (team X видит свой собственный контент, и никто другой не может видеть их).
Я не уверен, что лучше, поэтому:
- могу ли я выполнять поиск по SVN с использованием тегов (конечно, не тегов SVN, больше похожих на теги stackoverflow)?
- Есть ли смысл думать о дублировании — как SVN, так и SQL -содержимого?
- Есть другие предложения?
Редактировать
Приложение позволяет пользователям писать тесты проверки, которые они позже выполняют. Эти тесты являются общими для многих групп на разных сайтах. Нам нужно управление версиями по обычным причинам — отменить изменения, внезапные удаления и т.д. Это требует SVN.
Дело в том, что мы также хотим добавить опцию поиска всех тестов, помеченных как «срочные» и выполненных к настоящему времени, для целей отслеживания.
Надеюсь, теперь я выразился более ясно 🙂
Правка II
Я столкнулся с SvnQuery, и он выглядит неплохо, но есть ли у него API, который я могу использовать? Я бы предпочел использовать их механизм с моим собственным графическим интерфейсом.
ПРАВКА III
Мой коллега настоятельно поддерживает использование только базы данных и забывает о хранилище на основе файлов. Он утверждает, что это лучше для сохранения (что необходимо — тест — это больше, чем список команд для выполнения). Я был бы признателен за информацию по этому вопросу, поскольку я думаю, что должно быть возможно сделать это так или иначе.
Спасибо!
Комментарии:
1. Я никогда не рассматривал возможность использования svn в качестве хранилища документов для приложения, но идея интригующая.
2. Каковы требования к производительности и каков ожидаемый размер архива.
3. Является ли SharePoint вариантом?
4. Я не слишком хорошо это знаю, кроме того, что знаю, что с их веб-сайтами неудобно работать. Если ваше предложение касается веб-сайта, вероятно, нет. Если вы предложите что-то еще, пожалуйста, предоставьте более подробную информацию, спасибо!
Ответ №1:
Во-первых, рассмотрите возможность использования GIT, а не SVN. Это намного быстрее, и я подозреваю, что это более подходит в вашем случае использования: оно предназначено для распространения, что означает, что ваши пользователи смогут использовать его без доступа в Интернет, и у вас не будет никаких накладных расходов, связанных с обменом данными с сервером при сохранении документов.
Кроме этого, я не до конца понимаю ваш вопрос, но, похоже, его суть лучше перефразировать следующим образом: «Могу ли я выполнять поиск на основе тегов / ограничение доступа в моей системе управления версиями, или мне нужно создать слой поверх для этого?»
Если это так, то ответ заключается в том, что вам нужен слой сверху. Некоторые из них уже существуют, как на веб-основе (например, Trac), так и на настольных компьютерах (например, GitX). Они не обязательно будут реализовывать именно то, что вам нужно, но они могут стать хорошей отправной точкой для достижения того, что вы ищете.
Комментарии:
1. Если бы я мог — это не одобряется, поскольку мы в компании работаем в основном с SVN. Есть ли такой слой поверх для SVN (для настольных компьютеров, а не для Интернета)?
2. Кроме того, я не возражаю против реализации уровня выше. Вопрос в том, возможно ли каким-либо образом помечать файлы в SVN тегами, которые позволят выполнять запросы к ним?
3. Trac работает для SVN «из коробки», да, но я бы все же посоветовал GIT, иначе любое сохранение ваших файлов будет подвергнуто обходу, как только ваш репозиторий достигнет определенного размера. И да, вы можете установить / получить / удалить свойства svn для файлов. Однако, насколько мне известно, это не позволит вам легко запрашивать файлы / наборы изменений на основе их содержимого: здесь становится полезным дополнительный уровень.
4. git не очень хорошо работает с двоичными файлами, поэтому примите этот совет со всей серьезностью. Кроме того, если вы пытаетесь использовать общий доступ в git, помните, что вам все равно придется настраивать центральное хранилище и постоянно обращаться к нему — вы также можете использовать SVN, если работаете в такой конфигурации.
5. @gbjbaanb: Разве SVN и GIT не одинаково плохо работают с двоичными файлами? 🙂
Ответ №2:
Вы могли бы использовать SVN.
- Общие файлы: очевидно и просто. Оно также поддерживает централизованную блокировку, которая может понадобиться для двоичных файлов.
- Версии. Очевидно.
- Поиск… Теперь мы вступаем на трудную территорию. Существует дополнение Lucene, которое позволяет выполнять поиск в вашем репозитории в Интернете — opengrok, svnquery или svn-search. Это были бы ваши лучшие отправные точки для этого.
- Невозможно запретить людям видеть, что присутствует в репозитории svn, но вы можете запретить им доступ к нему. Я не знаю, можно ли легко расширить контроль доступа, чтобы предоставить скрытые папки, вы могли бы спросить разработчиков svn.
Есть несколько отличных API для работы с SVN, вероятно, наиболее доступным является SharpSvn, который предоставляет вам сборку .net, но есть Python, C и другие доступные.
Как уже упоминалось, существуют веб-инструменты, которые располагаются поверх SVN для предоставления доступа к нему, есть Trac и Redmine, а также несколько репозиториев, таких как WebSVN, так что есть много примеров кода, которые можно использовать для создания собственного.
Вы бы использовали DVCS, такие как git или mercurial? Я бы не стал. Хотя сами по себе они имеют хорошие механизмы, не похоже, что это то, что вам нужно. Это позволяет пользователям работать самостоятельно и предоставлять общий доступ другим на одноранговой основе (хотя вы можете установить «центральное» хранилище и работать с ним как с равным для всех). Они не работают централизованно, совместно. Например, если мы с вами оба редактируем тестовый пример локально, а затем отправляем его в центральное хранилище, у нас могут возникнуть проблемы при слиянии. У нас возникнут проблемы со слиянием, если файл является двоичным или иным образом не поддающимся объединению файлом. В этом случае у вас проблема с потерей изменений одного пользователя. Это одна из основных причин отказа от использования DVCS в вашем случае.
Если вы пытаетесь объединить общие тесты, смотрели ли вы на некоторые приложения, которые уже делают это? Недавно я заметил, что TestRail звучит похоже на то, что вы пытаетесь сделать. Это не бесплатно (увы), но дешево.