svn репозиторий на общем сетевом ресурсе Windows

Безопасно ли для нескольких компьютеров одновременно обращаться к хранилищу svn, хранящемуся в общей файловой системе?svn репозиторий на общем сетевом ресурсе Windows

Я создаю приложение, в котором каждый клиентский компьютер Windows имеет локальный рабочий набор файлов и может периодически синхронизироваться с остальной частью команды. С точки зрения сервера, я бы хотел полагаться только на общую точку монтирования Windows. Поддерживает ли файл svn файл: // URL-адрес совместно используемых файловых систем или предполагает, что файловая система является локальной?

Subversion docs упоминает проблемы с BDB и FSFS в средах Win9x, но мне непонятно, могут ли репозитории одновременно обращаться через файл: // URL-адреса безопасны в более поздних версиях Windows (или других операционных системах, для этого дело).

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

источник

2009-08-17 Patrick Linskey

В чем проблема, которую вы на самом деле пытаетесь решить/ограничения, с которыми вам приходится работать? –

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

Сверху моей головы (и я не мог найти какую-либо информацию в Интернете), я думаю, что если вы используете SVN-клиент, который поддерживает файл: // protocol (TortoiseSVN, например), он должен работать правильно.

Однако, к сожалению, я не могу найти документ, я помню, что есть определенные проблемы с файлом: // protocol и SVN. Если возможно, я бы предложил настроить SVN-сервер (VisualSVN работает очень красиво и легко настраивается) вместо того, чтобы полагаться на общий ресурс Windows.

Редактировать: Я нашел this discussion на Stackoverflow. Кажется, что с файловым протоколом проблем нет.

Редактировать 2: Ссылка Нейла - это то, что я прочитал некоторое время назад и препятствует файловому протоколу. Однако, если использование протокола file: // означает разницу между использованием и использованием источника управления, я бы рекомендовал хотя бы использовать это. Некоторое управление источником лучше, чем ничего.

источник

2009-08-17 19:18:53 JasCav

Я согласен с использованием VisualSVN над долей. – Nick

Я не согласен с вашим вторым изменением - ненадежный контроль источника хуже, чем никто. – 2009-08-17 19:28:53

Документы Tortoise SVN фактически сильно обескураживают его - см. this link. .

Резюмируя:

файла: // доступ предназначен для локального, доступа однопользовательских только, в частности тестирования и отладка.

источник

2009-08-17 19:19:56

Это документы TortoiseSVN, а не сами документы svn. Интересно, это ограничение или мнение парней TortoiseSVN или проблема с svn. Кроме того, я готов сделать много уступок в отношении ограничений окружающей среды; если я смогу найти узкий набор требований, которые * работают *, я с радостью буду им привязан (при условии, что одним из требований не является «запуск серверного процесса»). –

Я как-то подозреваю, что разработчики Tortoise знают немного больше о Subversion, чем вы или я. Черепаха построена на коде Subversion, поэтому я предполагаю, что это основное ограничение Subversion. – 2009-08-17 19:35:03

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

Я думаю, вы настроились на проблемы с этим подходом. Windows CIFS (протокол обмена файлами Windows) имеет множество известных проблем с возможностью блокировки и одновременной модификации, поэтому он либо будет медленным, небезопасным, либо тем и другим.

Много, много, лучшим решением является создание реального SVN-сервера вместо использования файла: // URL-адреса.

источник

2009-08-17 19:23:19

Я доволен «собакой медленной», как выясняется. Даже «кошка медленно» будет в порядке. Просто не «небезопасно». Я понимаю, что настройка сервера - это лучший подход, но это не вариант для этого продукта, к сожалению. –

То, как мы это делали в Windows, должно было использовать Apache для обслуживания наших файлов. Here Мы очень довольны этой настройкой.

источник

2009-08-17 19:27:18 JBrooks

Или вы можете сделать инструмент для вас: сервер VisualSVN. – reinierpost

Это право брата ...

Я был там. Я также использовал файловую систему для совместного использования «svn server» между двумя машинами ... Единственное, что я получил, это поврежденные файлы и большие головные боли ...

Установлен сервер svn (CollabNetSubversion Server), а теперь все работает гладко ... За исключением случаев, когда я сам ввертываю его ... но это еще одна история ....

Cheers.

Aldo

источник

2009-08-17 19:38:22 aldux

Какие проблемы с коррупцией вы столкнулись? Использовали ли вы BDB или FSFS? Какую файловую систему вы использовали? –

Другой вопрос похож, но был задан вопрос: Re: производительность: Subversion protocol performance

СВН Книга рекомендует не использовать файл: // протокол для нескольких пользователей

Choosing a Server Configuration:

Не соблазняйтесь простой идеей га ving все ваши пользователи получают доступ к репозиторию напрямую через файл: // URL. Даже если репозиторий легко доступен для всех через сетевой ресурс, это плохая идея. Он удаляет любые уровни защиты между пользователями и репозиторием: пользователи могут случайно (или преднамеренно) повредить базу данных репозитория, становится трудно переносить репозиторий в автономный режим для проверки или обновления, и это может привести к беспорядку проблем с разрешением файлов (см. раздел «Поддержка методов множественного доступа к репозиторию»). Обратите внимание, что это также одна из причин, по которым мы предупреждаем о доступе к репозиториям с помощью URL-адресов svn + ssh: // - с точки зрения безопасности, это фактически то же самое, что и локальные пользователи, обращающиеся через файл: //, и это может повлечь за собой все те же проблемы если администратор не осторожны

источник

2009-08-17 19:43:55 crashmstr

Интересно ... спасибо за ссылку! Интересно, какие проблемы с коррупцией в репозитории они беспокоят. –

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

с технической точки зрения это вполне возможно использовать файл: // протокол с несколькими пользователями:

коррупция будет нЕ произойти на стандартном использовании СВН , поскольку подрывная деятельность использует свои собственные механизмы блокировки в FSFS. В противном случае книга SVN четко заявила бы, чтобы избежать такой настройки, как упоминалось в выпуске BDB.

Однако проблема real заключается в том, как ограничить доступ к базе данных репозитория, чтобы не получить доступ к данным репозитория с помощью любого другого произвольного инструмента?

Если вы используете файл: // каждый может открыть каждый файл в вашем репозитории SVN и изменить его содержимое, что приведет к повреждению репозитория.

Черт возьми, каждый пользователь может удалить весь репозиторий!

Вы не можете ограничить доступ к инструментам svn, и поэтому вы не должны использовать файл: // протокол.

источник

2009-08-17 20:56:21

UM, я думаю, что существует разница между FSFS и протоколом 'file:', нет? – sbi

Есть ли у вас какая-либо поддержка, почему коррупция не будет происходить или это основано на предположении (вероятно, законном), что ребята SVN избегают искажения файлов в любой среде? –

Как луга заявили: «Возможно, состояние гонки существует на сетевом ресурсе, потому что операции файловой системы, которые предполагаются атомарными (т.е. перемещение), не гарантируются атомом при доступе по сети». Однако я делаю не имеют никакого понимания в этом вопросе. –

svn репозиторий на общем сетевом ресурсе Windows

ответ

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