Как настроить общую рабочую копию в Subversion
Я все еще очень новый, используя Subversion.
возможно ли иметь рабочую копию на доступном сетевом ресурсе (c:svnprojectswebsite) что все (в данном случае 3 использования) могут проверять и фиксировать файлы? Нам не нужен сервер сборки, потому что это сайт asp, и дизайнеры привыкли к немедленным результатам при сохранении файла. Я мог бы попытаться показать им, как настроить его локально на своих машинах, но если бы мы могли просто поделиться файлами на сервере разработки и еще есть возможность совершить, когда кто-то это сделал, это было бы идеально.
простым решением было бы для всех нас использовать одно и то же имя пользователя subversion, и это, по крайней мере, позволило бы мне поместить файлы под контроль версий.
но можно ли проверить папку из SVN respository, но по-прежнему требовать, чтобы каждый человек входил в систему со своим пользователем/пропуском для фиксации?
EDIT: я пытаюсь взять наш текущий рабочий поток, который редактирует живую версию сайт, использующий расширения Frontpage или FTP. И переместите его на что-нибудь получше. В этом случае копия живого сайта на сервере разработки, который я настраиваю для отражения живого сервера, удаляет доступ к расширениям frontpage. Тогда дизайнеры все еще могут иметь тот же эффект мгновенного удовлетворения, но мне не придется беспокоиться, что они редактируют живые файлы. Даже использование общего пользователя / прохода в subversion по-прежнему является контролем версий. Это может быть не идеально, и если бы дизайнеры были программистами, я бы попытался получить их полностью на борту, но это просто не так. Это лучшее, что я могу сделать в этом случае и избежать огромной кривой обучения и остановки работы.
9 ответов
по моему опыту, это будет работать просто отлично из коробки. В моей компании мы имели эту установку в течение нескольких лет и не испытывали никаких проблем (за исключением очевидных, имеющих общую рабочую копию).
однако вы должны изучить наличие отдельных рабочих копий и триггера (крючка), который обновляет общее местоположение на коммитах, если вам нужна "живая" версия сайта.
вы не можете проверить рабочую копию, a рабочую копию - термин, используемый для кода, который уже был проверен. Если вы просите нескольких разработчиков работать с одним и тем же набором рабочих файлов одновременно, то вы серьезно подрываете одно из основных применений системы управления версиями, которое должно позволить вашим разработчикам вносить изменения независимо друг от друга, не нарушая ничего для кого-либо еще.
Что сказал, Если вы действительно хотите сделать это вы можете. С сервером Linux, способ пойти, чтобы каждый из ваших пользователей работает с другим агентом пользователя ssh (для машин windows, мы используем Pagent) С другим идентификатором ssh для каждого пользователя. Затем сервер svn распознает ssh-туннели из разных удостоверений как принадлежащие разным пользователям. К сожалению, я не знаю как это в Windows.
вам нужно использовать svnserve (легкий SVN-сервер, который поставляется с SVN) или Apache mod.
С ним вы можете настройки разрешений такой:
[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
Я знаю, что это старый нить, но я нашел его потому, что я пытаюсь сделать то же самое.
Я не думаю, что эту проблему можно решить с помощью subversion, хотя я пробовал несколько раз, и я думаю, что необходимость полностью законна.
прецедент, который появляется неоднократно для нас, - это сложные файлы конфигурации, которые поддерживаются вне приложения.
хорошим примером может быть Apache httpd.conf файлов. Они сложны и мы хотите отслеживать изменения в файлах. Мы не хотим, чтобы все использовали "root", потому что тогда мы не можем отслеживать, кто что сделал.
Mercurial может сделать это:
рабочие копии предназначены для каждого пользователя свое. И хранилища являются общими. Только человек, который проверил WC, может фиксировать изменения из него.
возможно, вы могли бы посмотреть на что-то другое, чем subversion, если вам не нужен сервер, например, распределенные VCS (bzr, git и mercurial популярны в эти дни), или вы должны посмотреть на услуги хостинга subversion.
совместное использование одной рабочей копии не рекомендуется. Это действительно разрушает цель контроля версий. Пожалуйста, не делай этого.
вы должны иметь свой репозиторий SVN, и каждый пользователь (со своим именем пользователя и паролем для доступа к репозиторию SVN) должен проверить свою собственную рабочую копию.
Это можно сделать на одном ПК (это ваша проблема, ПК с несколькими разработчиками разделяя его?), имея разные учетные записи пользователей ПК и имея людей проверить в свою собственную учетную запись, или даже путем совместного использования учетной записи пользователя ПК и имея людей проверить в другую рабочую папку. Я не думайте, что это особенно аккуратно или приятно, и если компания не может позволить себе ПК на разработчика в эти дни, то вряд ли стоит работать!
рекомендую:
каждый сотрудник имеет свою собственную рабочую копию на своем ПК.
должен быть Ant или Maven или аналогичный скрипт сборки, который позволит разработчику создавать и развертывать из своей рабочей копии на веб-сервере разработки, чтобы они могли видеть, как это происходит. Это может будьте просты ,как "копировать файлы в это общее место".
поскольку у каждого сотрудника есть свое имя пользователя/пароль SVN, вы можете увидеть, кто сделал какое изменение, и заблокировать людей, когда они покидают компанию.
Это может создать процесс, который дизайнер должен следовать, а не анархия у вас есть в настоящее время, но если это займет больше половины дня, чтобы забрать SVN и как запустить сценарий сборки для развертывания на веб-сервере разработки, то у тебя проблемы посерьезнее.
Я думаю, что вы продаете свою команду. Non-devs can легко научиться использовать SVN, особенно с чем-то вроде черепахи. Если вы собираетесь пройти через проблемы с настройкой SVN, просто дайте каждому отдельный логин и позвольте им работать над своей локальной рабочей копией. Выполните быструю и грязную автоматизированную сборку CruiseControl для извлечения из SVN для создания содержимого промежуточного сайта. Это просто немного больше работы, и результат будет намного лучше.
Я знаю, что это старый вопрос/wiki, но решение, которое пришло мне в голову, выглядит следующим образом.
проблема может быть сформулирована следующим образом: как мы можем использовать реальную систему управления версиями (например, SVN) и по-прежнему позволять нетехническим дизайнерам наслаждаться тем же циклом сохранения-предварительного просмотра-сохранения-предварительного просмотра, который они узнали и полюбили?
вопросы:
для того, чтобы реализовать все преимущества SVN, каждый пользователь должен иметь свою собственную рабочую копию. Это так оно и есть.
Если у вас все еще есть классический ASP (не .NET) в вашем приложении, легкий локальный сервер, такой как Cassini, не будет выполнять эту работу.
было бы предпочтительнее, чтобы пользователю не нужно было устанавливать или учиться использовать SVN-клиент, такой как (по общему признанию-простая) Черепаха.
мой подход:
создайте ветку в SVN для каждого пользователя
на каждом клиенте, предоставьте сопоставленный диск в рабочий каталог пользователя на сервере dev. Они будут использовать FrontPage, Expression, SharePoint designer или что-то еще, чтобы внести свои изменения здесь.
в IIS на dev-сервере создайте пользовательский веб-сайт (например,
alice.www.mysite.comилиbob.www.mysite.com) С пользовательских заголовков. Они будут просматривать сайт по этому URL-адресу, чтобы увидеть свои изменения. Это также позволяет им показывать свои изменения другим, прежде чем объединять их в ствол.использование CruiseControl.NET, предоставить задачи для проверки, обновления, добавления и фиксации изменений для каждой ветви пользователя. Выясните, как это сделать, чтобы каждый пользователь мог видеть только свои собственные задачи.
использование CruiseControl.NET, создайте задачу, которая объединит их изменения в trunk
использование CruiseControl.NET, создайте задачу, которая обновит реальный сайт dev (dev.www.mysite.com) с Объединенными изменениями. Этот сайт будет показывать работу каждого в сочетании, и выступает в качестве промежуточной и отладочной области. Если вы используете WAP, вы захотите, чтобы эта задача также запускала сборку.
звучит, как много шагов, но это действительно довольно просто. Создайте ветви, сопоставьте диски, настройте новые сайты IIS и позвольте им сойти с ума.
под обложками это точно так же, как предоставление им локальной установки IIS и разрешение им фиксировать свои изменения с помощью SVN, когда это необходимо, так же, как разработчики. Разница в том, что их рабочая копия находится на сервере, IIS/Cassini не должны быть на их коробке, и они будут использовать веб-интерфейс для выполнения действий SVN, таких как фиксация, обновление и т. д.
удачи!