Как настроить общую рабочую копию в Subversion?

Question

Я все еще очень новичок в использовании Subversion.

Возможно ли иметь рабочую копию в общей сетевой папке (c: \ svn \ projects \ website), которую каждый (в данном случае 3) может извлекать и фиксировать файлы? Нам не нужен сервер сборки, потому что это сайт asp, и дизайнеры привыкли получать немедленные результаты при сохранении файла. Я мог бы попытаться показать им, как настроить его локально на своих машинах, но если бы мы могли просто обмениваться файлами на сервере разработки и при этом иметь возможность фиксировать, когда кто-то закончил, это было бы идеально.

Простым решением для всех нас было бы использовать одно и то же имя пользователя Subversion, что позволило бы мне, по крайней мере, поставить файлы под контроль версий.

Но можно ли извлечь папку из репозитория svn, но при этом каждый человек должен войти в систему со своим пользователем / pass для фиксации?

РЕДАКТИРОВАТЬ: я пытаюсь взять наш текущий рабочий процесс, который редактирует LIVE-версию сайта с использованием Frontpage Extensions или FTP. И переместите это к чему-то ЛУЧШЕМУ. В этом случае копия живого сайта на сервере разработки, который я настроил для зеркалирования живого сервера, удаляет доступ к расширениям главной страницы. Тогда дизайнеры могут по-прежнему иметь тот же эффект мгновенного удовлетворения, но мне не нужно беспокоиться, что они редактируют живые файлы. Даже использование общего пользователя / pass в subversion по-прежнему является контролем версий. Это может быть не идеально, и если бы дизайнеры были на самом деле программистами, я бы попытался использовать их полностью, но это не так. Это лучшее, что я могу сделать в этом случае и избежать огромной кривой обучения и остановки работы.

Answer 1

По моему опыту, из коробки все будет работать нормально. В моей компании у нас была такая настройка в течение ряда лет, и у нас не было никаких проблем (кроме очевидных из наличия общей рабочей копии).

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

Answer 2

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

Тем не менее, если вы действительно хотите сделать это, вы можете. В случае с Linux-сервером каждый из ваших пользователей может использовать свой собственный пользовательский агент ssh (для машин с Windows мы используем Pagent ) с разными идентификаторами ssh для каждого пользователя. Затем пусть svn-сервер распознает ssh-туннели от разных пользователей как от разных пользователей. К сожалению, я не знаю, как настроить это в Windows.

Answer 3

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

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

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

Хорошим примером могут быть файлы apache httpd.conf. Они сложные, и мы хотим отслеживать изменения в файлах. Мы не хотим, чтобы все использовали «root», потому что тогда мы не можем отследить, кто что сделал.

Mercurial может сделать это:

Mercurial Multiple Committers

Answer 4

Вам необходимо использовать svnserve (облегченный сервер SVN, который поставляется с SVN) или мод Apache.

С его помощью вы можете настроить права доступа следующим образом:

[general]
password-db = userfile
realm = example realm

# anonymous users can only read the repository
anon-access = read

# authenticated users can both read and write
auth-access = write

Answer 5

Я знаю, что это старый вопрос / вики, но решение, которое пришло мне в голову, заключается в следующем.

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

Баллов:

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

• Если у вас все еще есть классический ASP (НЕ .NET) в вашем приложении, легкий локальный сервер, такой как Cassini, не справится с этой задачей.

• Было бы предпочтительно, чтобы пользователю не приходилось устанавливать или учиться использовать клиент SVN, такой как (по общему признанию, простой) Turtoise.

Мой подход:

• Создать ветку в SVN для каждого пользователя

• На каждом клиенте предоставьте подключенный диск в пользовательский рабочий каталог на вашем dev-сервере. Они будут использовать FrontPage, Expression, SharePoint дизайнер или что-то еще, чтобы внести свои изменения здесь.

• В IIS на сервере разработчика создайте пользовательский веб-сайт (например, alice.www.mysite.com или bob.www.mysite.com) с пользовательским заголовком узла. Они будут просматривать сайт по этому URL, чтобы увидеть свои изменения. Это также позволяет им показывать свои изменения другим, прежде чем объединить их в транк.

• Используя CruiseControl.NET, задайте задачи для проверки, обновления, добавления и фиксации изменений для каждой ветви пользователя. Узнайте, как сделать так, чтобы каждый пользователь мог видеть только свои задачи.

• Используя CruiseControl.NET, создайте задачу, которая объединит их изменения в ствол

• Используя CruiseControl.NET, создайте задачу, которая обновит реальный сайт разработчика (dev.www.mysite.com) с объединенными изменениями. Этот сайт покажет работу всех вместе, и действует как область подготовки и отладки. Если вы используете WAP, вам нужно, чтобы эта задача также вызывала сборку.

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

Под прикрытием это в точности то же самое, что дать им локальную установку IIS и позволить им при необходимости вносить свои изменения в SVN, как это делают разработчики. Разница в том, что их рабочая копия находится на сервере, IIS / Cassini не обязательно должен быть на их коробке, и они будут использовать веб-интерфейс для выполнения действий SVN, таких как фиксация, обновление и т. Д.

Удачи!

Answer 6

Я думаю, вы продаете свою команду коротко. Номера для разработчиков могут легко научиться использовать SVN, особенно с чем-то вроде черепахи. Если у вас возникнут проблемы с настройкой SVN, просто дайте всем отдельный логин и позвольте им работать со своей локальной рабочей копией. Выполните быструю и грязную автоматизированную сборку CruiseControl, чтобы использовать SVN для создания промежуточного содержимого сайта. Это просто немного больше работы, и результат будет намного лучше.

Answer 7

У вас должен быть свой SVN-репозиторий, и каждый пользователь (со своим собственным именем пользователя и паролем для доступа к SVN-репозиторию) должен получить свою рабочую копию.

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

Я рекомендую:

1. Каждый сотрудник имеет собственную рабочую копию на своем ПК.

2. Должен существовать сценарий сборки ANT или Maven или аналогичный, который позволит разработчику создавать и развертывать свою рабочую копию на веб-сервере разработки, чтобы они могли видеть, как это происходит. Это может быть просто как «копировать файлы в это общее местоположение».

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

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

Answer 8

Возможно, вы могли бы взглянуть на что-то, кроме subversion, если вам не нужен сервер, например на распределенные VCS (в наши дни популярны Bzr, git и mercurial), или вам стоит взглянуть на сервисы хостинга Subversion.

Совместное использование одной рабочей копии не рекомендуется. Это действительно побеждает цель контроля версий. Пожалуйста, не делай этого.

Answer 9

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