|
система контроля версий
|
|||
---|---|---|---|
#18+
Сразу извиняюсь за возможный оффтопик, но все же. На работе хотим ввести систему контроля версий, с этой целью хотел бы спросить какую Вы систему используете и Ваше мнение какую следует\не следует использовать и почему. Заранее спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2009, 21:52 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
Долгое время использовал ClearCase - только положительные впечатления. Subversion, SVN - отдыхают. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2009, 19:48 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
ClearCase не пробовал. Subversion aka SVN - практически, индустриальный стандарт :) Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2009, 20:17 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
Дмитрий ВебстерДолгое время использовал ClearCase - только положительные впечатления. Subversion, SVN - отдыхают. забыли упомянуть про стоимость лицензии: от 3600 до 4500 за единицу ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2009, 20:21 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
Помимо svn, можно еще поковырять распределенные системы контроля версий и решить, стоит ли оно того. Например, darcs (идея интересная) либо git (более монстровая, но более мейнстримовая, должна быть надежнее). ... |
|||
:
Нравится:
Не нравится:
|
|||
24.03.2009, 22:40 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
Пользуем FreeVCS для Delphi разработки, а также приспособили (легко) для контроля PL/SQL кода. Работает с любыми дб бекендами. Щас правда оно существует на сорсфорже под высеской JEDI VCS - еще не пробовали. И так все в полне устраивает. Да, оно бесплатное еще к тому же! )) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.03.2009, 23:04 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
svn, довольно давно. функционально и доступно из разных мест (офис, удаленно и т.п.). ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2009, 16:59 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
SVN, Tortoise, Delphi Plugin ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2009, 09:05 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
truel, ответ сильно зависит от средств разработки, количества разработчиков, инфраструктуры компании, количества денег, которые могут быть потрачены на CVS. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2009, 14:27 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
Visual Source Safe и Sharepoint. И тем и другим, в принципе доволен. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2010, 13:25 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
да реально всё равно. тут от организации процесса зависит больше чем от CVS если пишете на студии то VSS а точнее Team Suite ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2010, 15:05 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
Мы изначально использовали Source Safe + TestTrack. Потом перешли на SVN + TestTrack. Затем все это заменили на TFS. TFS используется для контроля исходного кода, он же используется для управления задачами и багами. Программисты и тестеры используют Visual Studio для работы с ним, все остальные работают через SharePoint-портал, который подключен к TFS. Особой разницы в функцинале портала и Team Explorer я не заметил. Все документы хранятся в Shared documents SharePoint-портала. Все документы одновременно доступны через Microsoft Groove (который у нас используется очень активно), SharePoint-портал или Visual Studio. Groove и SharePoint синхронизируются автоматически каждый час. Работа с файлами в Groove реализована значительно удобнее, чем в SharePoint, поэтому используем его. К сожалению календари, встречи и т.п. у Groove и SharePoint интегрировать не удалось. Все это по прежнему остается в Groove. Баги и таски тоже не удалось интегрировать в Groove. С какими сложностями пришлось столкнуться: 1. Как оказалось TFS может создавать бранчи только на основе каталогов файловой системы. Посколько у нас не все проекты Solution'а хранились в одном каталоге, при миграции от этого пришлось отказаться - т.е. пришлось переместить все проекты в один каталог. Несколько нелогично со стороны Microsoft - давать такую возможность в Visual Studio, но не предусмотреть ее в TFS. 2. Как оказалось, TFS не может складывать последние версии бранчей в один и тот же каталог - вместо этого он складывает их в разные каталоги. Это приводит в тому, что нельзя так же просто, как и раньше, когда мы работали с SVN, использовать IIS для отладки сайтов - в IIS для приложений пути прописаны в явном виде. Для того, чтобы использовать уже сконфигурированное приложение, после взятия последней версии нового бранча, нам приходится вручную исправлять пути приложений в IIS. Это несколько неудобно. Странно, что в Microsoft не предусмотрели решения такой, в общем-то довольно очевидной проблемы. 3. Как оказалось в студии по умолчанию нет поиска багов или тасков по номеру или подстроке - только запросы. Очень неудобно, особенно тестировщикам. К счастью для решения проблемы уже есть plug-in - http://visualstudiogallery.msdn.microsoft.com/en-us/3f31bfff-5ecb-4e05-8356-04815851b8e7 Из положительных результатов миграции хотелось бы отметить следующие: 1. Отсутствие зоопарка инструментов. Раньше был TestTrack, Groove, SVN. Теперь осталась только студия и немного Groove. 2. Возможность явной связи изменений в коде с багом или таском. Раньше такого не было и для выгрузки патча программистам приходилось писать в комментариях к багу список измененных файлов. Теперь стало очень удобно - при чекине в TFS можно легко ассоциировать чекин с багом или таском и потом по истории обновления бага или таска посмотреть историю изменений кода. Очень удобно. 3. Удобная возможность мержа кода от основной ветки разработки к стабильным бранчам для подготовки патчей (что было очень неудобно в SVN). 4. Высокий потенциал на будущее - возможность автоматизированных сборок на сервере, запуска unit-тестов, деплоймента и пр. Из недостатков: 1. Как оказалось в TFS нельзя назначить баг или таск сразу нескольким сотрудникам. В общем-то это небольшая проблема и требуется довольно редко. Можно сказать, что можно вполне обойтись и без этого. 2. В TFS нет как такового общего списка багов или тасков - вместо этого есть только запросы. В принципе ничего страшного, но потенциально существует опасность потерять какой-нибудь work item, составив неверный запрос. 3. При назначении человеку бага или таска у него не выскакивает сообщение, как это было в TestTrack Pro. Иногда полезно. 4. Списки багов и тасков не обновляются автоматически - приходится жать Refresh. 5. Нет возможности изменить историю работы с work item. Т.е. если в комментарии забыли что-то написать и хотим добавить - надо взять весь комментарий, скопировать его, вставить и уже потом исправлять. А в остальном все не плохо. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2011, 09:48 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
Приходилось работать с CVS, VSS, SVN. Последний нравится больше остальных. Интересная концепция у git (не работал сам с ней), но думаю не для каждого коммерческого проекта подойдет, где требуется чтобы было выделенное место централизованное где все исходники и их версии хранятся. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2011, 21:09 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
On 25.01.2011 21:09, Wireless wrote: > Интересная концепция у git (не работал сам с ней), но думаю не для каждого > коммерческого проекта подойдет, > где требуется чтобы было выделенное место централизованное где все исходники и > их версии хранятся. git позволяет иметь такое место, в чём проблема-то ? Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2011, 12:36 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
Wireless, Недавно перешел с SVN на Mercurial. Понял, что CVS и SVN вчерашний день. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2011, 12:43 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
MasterZivgit позволяет иметь такое место, в чём проблема-то ? Я понимаю что это можно автоматизировать, например, скриптом из крона... но что вы будете делать например с конфликатами? у централизованных систем контроля версий есть... централизованное место где гарантированно хранится консистентная закомиченная версия. git - децентрализованное хранилище. Как вы собираетесь выбирать какое хранилище "самое правильное"? Условными политиками среди разработчиков? ps. Не имею практического опыта с git, поэтому не исключаю что мой вопрос из категории STFM. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2011, 20:39 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
РеалистWireless, Недавно перешел с SVN на Mercurial. Понял, что CVS и SVN вчерашний день. А если сравнивать с git? :) Интересно, что на этой неделе второй раз про Mercurial слышу. Первый раз коллега про него рассказывал, сказал что концепция Mercurial - тот же git, разница в наборе команд в основном... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2011, 20:42 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
WirelessРеалистWireless, Недавно перешел с SVN на Mercurial. Понял, что CVS и SVN вчерашний день. А если сравнивать с git? :) Интересно, что на этой неделе второй раз про Mercurial слышу. Первый раз коллега про него рассказывал, сказал что концепция Mercurial - тот же git, разница в наборе команд в основном... Ртутный на Git очень похож, практически та же самая концепция, только мне Mercurial проще показался. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2011, 20:58 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
On 26.01.2011 20:39, Wireless wrote: > Я понимаю что это можно автоматизировать, Это не надо автоматизировать. Просто создать ещё один репозиторий, и называть его центральным. например, скриптом из крона... но что > вы будете делать например с конфликатами? Конфликты были, есть и будут везде, не толко в git, git их автоматом не решит, как и любая другая VCS. > у централизованных систем контроля версий есть... централизованное место где > гарантированно хранится консистентная закомиченная версия. git - > децентрализованное хранилище. Как вы собираетесь выбирать какое хранилище "самое > правильное"? Условными политиками среди разработчиков? "Просто создать ещё один репозиторий, и называть его центральным." У тебя просто централизировческая паранойя. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 11:14 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
On 07.03.2009 21:52, truel wrote: Я главное что ещё по теме сказал. Всё, что угодно, кроме VSS. Только не он. Он уже давно изжил себя. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 11:16 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
MasterZiv"Просто создать ещё один репозиторий, и называть его центральным." Никаких серьезных аргументов не услышал... Допустим, ваша компания работаете над коммерческим проектом и ваше начальство властно решает что MisterZiv будет еже{дневно/недельно/...} коммитить изменения на сервер в "центральный" репозиторий и разрешать при этом конфликты в разных ветках, над которой работают разные разработчики. MisterZiv этим успешно занимался пару месяцев, а потом забыл/забил/запил/уволился. Т.к. разработчики обычно сами между собой хорошо решали как изменения между их редакциями синхронизировать, не используя никаких "центральных" репозиториев, то об этом долго никто не вспоминал... ...пока не понадобилась ветка, над которой долго работал MisterZiv один. Расследование показало, что эти изменения нигде больше не сохранены, то бишь утеряны. Реальный сценарий? На мой взгляд вполне. Понятно, что такие вещи можно исключить жесткими политиками среди разработчиков, но это все искусственно. На мой взгляд, git/mercurial - удобно для разработчиков, но это добавляет риски с точки зрения компании. Буду рад услашть что я ошибаюсь. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 20:21 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
On 27.01.2011 20:21, Wireless wrote: > ...пока не понадобилась ветка, над которой долго работал MisterZiv один. > Расследование показало, что эти изменения > нигде больше не сохранены, то бишь утеряны. Реальный сценарий? На мой взгляд вполне. Это проблемы любого VCS. Подумай над проблемой, когда человек долго-долго работал над чем-то, сделал, уволился, но не закоммитил всё в репозиторий, скажем, VSS-а. Всё то же самое, только в git у человека есть ещё свой локальный репозиторий кода, слияние кода из которого в центральный репозиторий абсолютно аналогично тому, что я описал. > Буду рад услашть что я ошибаюсь. Услыш. Ошибаешься. Риски -- это когда ты теряешь этот репозиторий со всем кодом без возможности восстановить код и его историю. А это -- просто работа. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2011, 11:38 |
|
система контроля версий
|
|||
---|---|---|---|
#18+
Правильно, но в не-git/HG системах контроля версий такая вероятность намного меньше. Разработчик _вынужден_ коммитить в центральный репозиторий чтобы команда увидела их изменения. В git - это опционально, они могут вообще ничего туда не коммитить и процесс разработке в команде будет идти. Риски -- это когда ты теряешь этот репозиторий со всем кодом без возможности восстановить код и его историю. Ну-ну... вы много видели рабочих станций с raid-зеркалами? У меня был на одной работе, но это все-таки экзотика. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.02.2011, 21:46 |
|
|
start [/forum/topic.php?fid=37&fpage=7&tid=1555481]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
33ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 274ms |
total: | 406ms |
0 / 0 |