Применение CVS в WEB-разработках

[young]

Применение CVS в WEB-разработках

Задача ставится не для удаленной команды, а для ребят сидящих внутри одной комнаты.

На сегодняшний день мне извесно три подхода

1) Имеется CVS репозиторий, у каждого разработчика своя локальная копия
минусы: много копий, много места, много доменов, вобщем - не устраивает

2) Имеется CVS репозиторий, одна локальная копия, при работе c CVS у всех один логин
Уже лучше чем вариант 1, но все равно есть минусы

3) Имеется CVS репозиторий, одна локальная копия, при работе c CVS у каждого свой логин
Просто идеальный вариант, кроме одного минуса: я не знаю как это реализовать

Из чего два вопроса
1) реализуем ли вариант 3, если да то как?
2) есть ли еще какие-то варианты?

 

[si]

1) Имеется CVS репозиторий, у каждого разработчика своя локальная копия
минусы: много копий, много места, много доменов, вобщем - не устраивает

правильный подход

2,3 - как ты будешь редактировать 1 файл в двоем ? диск в 160G стоит 100$ ...

 

[Krisha]

young
Гм, я не совсем понял в чем проблемма, понятно, что репозиторий один, а доступ к нему имеет несколько программистов - это имхо единственно правильный вариант.

Ты не знаешь как настроить CVS сервер, чтобы разные товарищи могли работать с одни репозиторием ?

-~{}~ 29.03.04 10:01:

Да, ессное дело, что к третъему пункту еще и у каждого локальная копия

 

[young]

si
Значит тогда я чего-то не допонемаю.
У каждого локальная копия - без проблем.
Но перед внесением их в репозиторий хотелось бы проверить их на работоспособность. Т.е. посмотреть на вебе.
Так что, каждому девелоперу кроме репозитории давать еще и виртуалхост с доменом?

 

[confguru]

У нас такой..

1) Имеется CVS репозиторий, у каждого разработчика своя локальная копия
минусы: много копий, много места, много доменов, вобщем - не устраивает

Вижу только плюсы..
Каждый имеет свою копию и разрабатывает свой кусок
возможно ветку или патч...
Сразу проверяет на своей машине..

Место? Имхо 10Гб за глаза хватает.. Правда ДБ сервер на отдельной
машине желательно... это критично для миллионных баз..

Много доменов? В чем проблемма дописать в HOSTS
+ сейчас пишем тесты для модулей через бинарник php

Имхо нормальная схема..

 

[tony2001]

young
а кто просит каждый раз апдейтить рабочий сервер из CVS ?
пускай всё выкладывается на тестовый сначала.
а лучше - разделить на 2 ветки - DEV & STABLE.
в DEV идет вся разработка, а STABLE периодически с ней синхронизируется.

 

[confguru]

Да - забыл добавить - у каждого проекта hostdepended
конфиг.. причем чтоб поднять проест на своей машине достаточно сделать
симлинки в каталоге настроек

 

[young]

Так-с, значит что я понял.

У каждого своя рабочая копия и домен вида young-dev.domen.org
После каждого изменения, проверенного и законченого у себя в копии, и выполнения тестов, все это дело коммитися.
Раз в неделю делается CVS-UP на домен qa.domen.org где оно проверяется тестерами.

Когда система является стабильной, ей ставится CVS-TAG stable_v_NN

правильно?

2tony:

а лучше - разделить на 2 ветки - DEV & STABLE.

В чем преимущество веток перед маркировкой тегами?

2admin:

Правда ДБ сервер на отдельной
машине желательно... это критично для миллионных баз..

кстати, да. Для каждого девелопера надо и отдельную БД.

PS: Нет господа, лично я пока склоняюсь к тому, что одна локальная копия и все работают под общим логином.

 

[Brezee]

"кстати, да. Для каждого девелопера надо и отдельную БД."
это совсем не обязательно!!!
У нас например одна БД и все ок, даже так лучше всегда тестовые данные кто-то добавил в ДБ

 

[confguru]

Я про то что если ставить локальные копии MySQL,Postgres, DB2
то комп сильно проседает а вот создать на отдельном сервере
базу имяпроекта_девелопер проблем нет

 

[Brezee]

Есть кстати вопрос, а кто чем пользуется (какой именно системой контроля версий):

1. CVS
2. VSS
3. StarTeam
4. ?????

Я понимаю что первая выигрывает от того что она не комерческая, ну а если все-таки отбросить данный фактор, то что же могло бы претендовать на "лучше всех"!

 

[Krisha]

young
Так делать нехорошо, каждый должен работать со своей локальной копией.

1. внес извенения в свою локальную копиию
2. протестил
3. закоммитил

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

Если все будут работать под одним логином вы не будите знать кто и что наворотил.

Brezee
Мы юзаем CVS

 

[Brezee]

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

 

[confguru]

Brezee

Так же кто-то грохнул нужные тебе данные.. )

 

[tony2001]

>а можно ли в CVS визуально просмотреть различия между любыми версиями одного и того же файла?
cvs diff - это визуально?

>и еще как там решается вопрос с одновременным доступом двух разработчиков?
пока идет коммит одного - другие ждут.
хотя, коммит обычно достаточно "атомарная" операция.

 

[young]

tony2001
плс, прокомментируй

В чем преимущество веток перед маркировкой тегами?

 

[tony2001]

young
это разные вещи.

 

[confguru]

Еще можно залочить файлики если изменения очень важны..

 

[Krisha]

Brezee
1. Да, можно, это называется: "Diff selected"
2. Схема такая: 2 разработчика заапдейтили из CVS файл и начали с ним работать, потом один из разработчиков закоммитил, следующий уже не сможет закоммитить пока не сделает апдейт.

 

[Brezee]

Автор оригинала: Krisha
Brezee
1. Да, можно, это называется: "Diff selected"
2. Схема такая: 2 разработчика заапдейтили из CVS файл и начали с ним работать, потом один из разработчиков закоммитил, следующий уже не сможет закоммитить пока не сделает апдейт.

Возникает вопрос а он будет видеть что ему необходимо сделать апдейт перед разработкой, иначе если он ввел паралельно работу с этим файлом то придется делать слияние версий (merge), или нужно взять за правило - перед разработкой всегда делать апдейт.???

P.S. В VSS это делается автоматом, как только я делаю checkout я получаю новую версию файла, если даже я и забыл сделать "get latest version"...