Как настроить общий рабочий экземпляр в Subversion

Question

Я все еще очень новый, используя Subversion.

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

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

Но можно ли проверить папку из репозитория svn, но все же требуется, чтобы каждый пользователь заходил с помощью своего пользователя/pass для совершения?

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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

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

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

Answer 6

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

С его помощью вы можете configure permissions так:

[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 7

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

Answer 8

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

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

Очки:

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

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

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

Мой подход:

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

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

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

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

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

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

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

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

Удачи !

Answer 9

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

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

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

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

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

Mercurial Multiple Committers