-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Что вы используете в разработках SVN(Subversion) vs CVS
- Автор темы confguru
- Дата начала
diamond_krnl
pure-php
CSV - в команде из 3х прогеров, лишний геморой. 
![[DAN]](/talk/data/avatars/m/0/23.jpg?1320946380){kind=avatar}
diamond_krnl
CSV может быть и геморой, каждому офис надо ставить..
По моему мнению где есть 2 программиста уже нужна
система контроля версий.
Есть даже частный случай - когда ты дорабатываешь чужой
код - то не плохо начальную версию тоже положить в
систему контроля версий, чтоб можно было откатить определенный функционал.
CSV может быть и геморой, каждому офис надо ставить..
По моему мнению где есть 2 программиста уже нужна
система контроля версий.
Есть даже частный случай - когда ты дорабатываешь чужой
код - то не плохо начальную версию тоже положить в
систему контроля версий, чтоб можно было откатить определенный функционал.
BOJIK
Новичок
Я даже когда один работаю использую SVN , причем храню там все и код и документацию, правда, в разных репозиториях. А вообще, использовать систему контроля версий это ИМХО хороший стиль.
Использую SVN потому как там есть фичи которых нет в CVS (удаление, переименование файлов в репозитории).
Использую SVN потому как там есть фичи которых нет в CVS (удаление, переименование файлов в репозитории).
svetasmirnova
маленький монстрик
А почему нельзя указать оба? Я в одних проектах SVN использую, в других CVS. Зависит от ограничений. SVN вроде удобнее, потому за неё проголосовала.
Groove
Вот интересный отзый.. для GPRS весьма актуален..
Недавно перешли с CVS на SVN. Очень доволен.
Перешли по следующим причинам:
SVN без проблем работает с папками (тоже версионно), без проблем периименовать файл или папку ...
SVN отлично работает с бинарниками, при этом по сети в любом случае посылаються только изменения а в CVS при коммите файлы посылаються целиком (в том числе и не бинарные)
SVN работает транзакциями, у вас не будет ситуации как в
CVS когда вы коммитите 10 файлов а на 5 у вас проблемы происходит ошибка, на сервер у вас теперь часть исправленных файлов а часть нет, в SVN произойдет откат.
Вот интересный отзый.. для GPRS весьма актуален..
Недавно перешли с CVS на SVN. Очень доволен.
Перешли по следующим причинам:
SVN без проблем работает с папками (тоже версионно), без проблем периименовать файл или папку ...
SVN отлично работает с бинарниками, при этом по сети в любом случае посылаються только изменения а в CVS при коммите файлы посылаються целиком (в том числе и не бинарные)
SVN работает транзакциями, у вас не будет ситуации как в
CVS когда вы коммитите 10 файлов а на 5 у вас проблемы происходит ошибка, на сервер у вас теперь часть исправленных файлов а часть нет, в SVN произойдет откат.
striimii
Guest
Ответил CVS, потому что Zend Studio, к сожалению, пока работает только с ним, а следовательно, с ним приходится работать и мне
Зендостроители обещали SVN-поддержку, вопрос только в какой версии... Как только встроят, то переведу проекты на SVN.
Его плюсы очевидны и хорошо расписаны постом выше.
Зендостроители обещали SVN-поддержку, вопрос только в какой версии... Как только встроят, то переведу проекты на SVN.
Его плюсы очевидны и хорошо расписаны постом выше.
tony2001
TeaM PHPClub
Совершенно не понимаю необходимости переходить куда-то с работающего годами ПО.
Можете считать меня упёртым консерватором, но все эти доводы для меня ничего не стоят.
По пунктам:
>SVN без проблем работает с папками (тоже версионно), без проблем периименовать
> файл или папку ...
это первый довод, который все приводят в пользу SVN.
но! вы часто переименовываете что-то в SVN?
у меня такая необходимость возникает максимум раз в год.
редко используемая и сомнительная фича.
>SVN отлично работает с бинарниками
cvs add -kb ?
>при этом по сети в любом случае посылаються только изменения а в CVS при
>коммите файлы посылаються целиком (в том числе и не бинарные)
опять же, бинарные файлы в CVS добавляются очень редко, ибо нет особого смысла, кроме "хранения всех яиц в одной корзине".
>SVN работает транзакциями, у вас не будет ситуации как в
>CVS когда вы коммитите 10 файлов а на 5 у вас проблемы происходит ошибка, на
> сервер у вас теперь часть исправленных файлов а часть нет, в SVN произойдет откат.
очень хорошо.
но. я ни разу не сталкивался с такой ситуацией при использовании CVS (за ~4 года использования, из них несколько месяцев - сугубо через GPRS или плохой коннект).
резюме:
не вижу смысла переводить существующие и нормально работающие репозитарии на что-то другое. работает - не трогай.
мода - она проходит. через год появится какой-нибудь FGH и все будут массово тратить время на перевод рабочих проектов под неё.
пускай тратят.
Можете считать меня упёртым консерватором, но все эти доводы для меня ничего не стоят.
По пунктам:
>SVN без проблем работает с папками (тоже версионно), без проблем периименовать
> файл или папку ...
это первый довод, который все приводят в пользу SVN.
но! вы часто переименовываете что-то в SVN?
у меня такая необходимость возникает максимум раз в год.
редко используемая и сомнительная фича.
>SVN отлично работает с бинарниками
cvs add -kb ?
>при этом по сети в любом случае посылаються только изменения а в CVS при
>коммите файлы посылаються целиком (в том числе и не бинарные)
опять же, бинарные файлы в CVS добавляются очень редко, ибо нет особого смысла, кроме "хранения всех яиц в одной корзине".
>SVN работает транзакциями, у вас не будет ситуации как в
>CVS когда вы коммитите 10 файлов а на 5 у вас проблемы происходит ошибка, на
> сервер у вас теперь часть исправленных файлов а часть нет, в SVN произойдет откат.
очень хорошо.
но. я ни разу не сталкивался с такой ситуацией при использовании CVS (за ~4 года использования, из них несколько месяцев - сугубо через GPRS или плохой коннект).
резюме:
не вижу смысла переводить существующие и нормально работающие репозитарии на что-то другое. работает - не трогай.
мода - она проходит. через год появится какой-нибудь FGH и все будут массово тратить время на перевод рабочих проектов под неё.
пускай тратят.
svetasmirnova
маленький монстрик
Ты не прав. Бинарники - это и документация в формате doc/ppt/xls (не нужно сразу критиковать: это меняющаяся конечная документация, предназначенная для клиентов) плюс при разработке сайтов бывают варианты разработки дизайна, и опять-таки удобно хранить изображения в репозитории.
А с резюме согласна
tony2001
TeaM PHPClub
>это и документация в формате doc/ppt/xls
CVS/SVN - системы для контроля за изменениями.
с бинарниками всё равно не получится эти изменения отслеживать, поэтому хранятся они в CVS/SVN или нет - без разницы.
единственное преимущество - всё в одном месте лежит.
поэтому аргумент "лучше работает с бинарниками" никакой ценности не несет.
CVS/SVN - системы для контроля за изменениями.
с бинарниками всё равно не получится эти изменения отслеживать, поэтому хранятся они в CVS/SVN или нет - без разницы.
единственное преимущество - всё в одном месте лежит.
поэтому аргумент "лучше работает с бинарниками" никакой ценности не несет.
svetasmirnova
маленький монстрик
Ну что-то типа "at revision 55" мы всё равно получим
MiRacLe
просто Чудо
На опрос я не ответил, но хочется попросить "отвечающих" - а как имеенно "настроить и использовать cvs-svn" в "конкретных" условиях:
есть проект "vasya.ru", он как "vasya.lan" - локальный http-сервер, есть "vasya.ru" - там где будет(уже находится) production-сервер, есть 2(редко 3 и больше) программиста и N (число не подверженное оценке) дизайнеров-верстальщиков(-иц), способных поправить-исправить-изменить шаблоны.
Собственно вопрос не в том как заставить всех участников проекта заставить делать commit после изменений файлов, к этому со временем привыкнут все(человек - не животное, привыкает ко всему), а в том как эти изменения попадут в $_SERVER['DOCUMENT_ROOT'] ?
Был бы благодарен на "русскоязычный" ресурс по теме. На XPoint началась-было статья .... но пока в стадии "underconstruction", множество идей-рассуждений-конкретных решений для производства программного обеспечения отличного от web - я бы(и соратники-коллеги-сотрудики) могли иметь свой локальный сервер со своими файлами и ревизиями и коммитить изменения в общий репозитарий и тогда вроде всё понятно, но по-настоящему любопытно как это делается у "белых людей"....
есть проект "vasya.ru", он как "vasya.lan" - локальный http-сервер, есть "vasya.ru" - там где будет(уже находится) production-сервер, есть 2(редко 3 и больше) программиста и N (число не подверженное оценке) дизайнеров-верстальщиков(-иц), способных поправить-исправить-изменить шаблоны.
Собственно вопрос не в том как заставить всех участников проекта заставить делать commit после изменений файлов, к этому со временем привыкнут все(человек - не животное, привыкает ко всему), а в том как эти изменения попадут в $_SERVER['DOCUMENT_ROOT'] ?
Был бы благодарен на "русскоязычный" ресурс по теме. На XPoint началась-было статья .... но пока в стадии "underconstruction", множество идей-рассуждений-конкретных решений для производства программного обеспечения отличного от web - я бы(и соратники-коллеги-сотрудики) могли иметь свой локальный сервер со своими файлами и ревизиями и коммитить изменения в общий репозитарий и тогда вроде всё понятно, но по-настоящему любопытно как это делается у "белых людей"....
tony2001
TeaM PHPClub
>а в том как эти изменения попадут в $_SERVER['DOCUMENT_ROOT'] ?
да как угодно.
смысла делать это автоматически нет (хотя, я никаких проблем не вижу в реализации - к CVS цепляются в разные места какие угодно скрипты, можно, например, копировать измененный файл куда-то), т.к. процесс установки чего-то всё равно требует человеческого участия.
обычно разработка идёт в основной ветке, а на каких-то этапах код объявляется стабильным и от основного ствола ответвляется бранч версии (условно, VERSION_2_3_0).
далее, код из бранча идёт в использование.
да как угодно.
смысла делать это автоматически нет (хотя, я никаких проблем не вижу в реализации - к CVS цепляются в разные места какие угодно скрипты, можно, например, копировать измененный файл куда-то), т.к. процесс установки чего-то всё равно требует человеческого участия.
обычно разработка идёт в основной ветке, а на каких-то этапах код объявляется стабильным и от основного ствола ответвляется бранч версии (условно, VERSION_2_3_0).
далее, код из бранча идёт в использование.
svetasmirnova
маленький монстрик
>Был бы благодарен на "русскоязычный" ресурс по теме.
www.cvs.ru
-~{}~ 13.07.05 00:21:
>>а в том как эти изменения попадут в $_SERVER['DOCUMENT_ROOT'] ?
>да как угодно
Кстати, можно автоматом. То есть из репозитория можно прямо туда и обновлять.
www.cvs.ru
-~{}~ 13.07.05 00:21:
>>а в том как эти изменения попадут в $_SERVER['DOCUMENT_ROOT'] ?
>да как угодно
Кстати, можно автоматом. То есть из репозитория можно прямо туда и обновлять.
slach
Новичок
у нас особо выбор не стоял
поскольку вносили в репозиторий "с нуля", то выбрали SVN
вообще ИСПОЛЬЗОВАНИЕ системы контроля версий, сильно зависит от ДИСЦИПЛИНИРОВАННОСТИ программиста
по моей практике очень сложно УБЕДИТЬ человека, делать commit своевременно, если он не считает нужным делать этот коммит
некоторые (как я время от времени) делают коммиты при изменении даже пары строк даже если это не является багфиксом
некоторые только при внедрении какой то фичи... но часто бывает что пока одна Features не доделана, начинают делать другую... в итоге в репозитории сло
сложно заставить давать вразумительный комментарий к коммиту
самая большая полезность которая мне была от SVN когда у меня убился винт
то слил просто все working copy из SVN ... и работа практически не остановилась
поскольку вносили в репозиторий "с нуля", то выбрали SVN
вообще ИСПОЛЬЗОВАНИЕ системы контроля версий, сильно зависит от ДИСЦИПЛИНИРОВАННОСТИ программиста
по моей практике очень сложно УБЕДИТЬ человека, делать commit своевременно, если он не считает нужным делать этот коммит
некоторые (как я время от времени) делают коммиты при изменении даже пары строк даже если это не является багфиксом
некоторые только при внедрении какой то фичи... но часто бывает что пока одна Features не доделана, начинают делать другую... в итоге в репозитории сло
сложно заставить давать вразумительный комментарий к коммиту
самая большая полезность которая мне была от SVN когда у меня убился винт
то слил просто все working copy из SVN ... и работа практически не остановилась