Наша фирма уже более года работает с CVS.
В принципе нас всё устраивает.
Я слышал что многие переходят с CVS на SVN.
Стоит ли переходить с CVS на SVN и почему?
Заранее благодарен за ответ.
13.09.07 16:06: Перенесено модератором из 'Java' — Blazkowicz
Здравствуйте, irbis81, Вы писали:
I>Наша фирма уже более года работает с CVS. I>В принципе нас всё устраивает. I>Я слышал что многие переходят с CVS на SVN. I>Стоит ли переходить с CVS на SVN и почему?
I>Заранее благодарен за ответ.
Хм... а причём тут java ? Это больше похоже общие вопросы программирования -> управление проектами
Здравствуйте, irbis81, Вы писали:
I>Наша фирма уже более года работает с CVS. I>В принципе нас всё устраивает. I>Я слышал что многие переходят с CVS на SVN. I>Стоит ли переходить с CVS на SVN и почему?
I>Заранее благодарен за ответ.
Если вас всё устраивает, то может и не стоит. Но с другой стороны, у CVS нет никаких преимуществ перед SVN, а вот у SVN перед CVS полно.
Щас меня тут начнут всячески позорить, но тем не менее... Вопрос из серии "я использую PHP 4, пацаны сказали, надо брать PHP 5". Вместо PHP 4 и 5 подставить по вкусу.
I>В принципе нас всё устраивает.
Ключевая фраза. CVS — полноценная система контроля версий. Полноценная — в том смысле смысле базовые СМные принципы и операции она реализует. Если за год не потребовалось ни разу чего-то особенного, что есть в SVN — то и не надо ничего менять.
I>Я слышал что многие переходят с CVS на SVN.
Зачастую это переход из люботыпства по принципу "ну это же круче! почему не использовать?" Лучшее — враг хорошего.
Я понимаю, если бы стоял вопрос о выборе системы контроля версий с нуля или о переходе с какого-нибудь SourceSafe на что-то другое — тут спору нет, SVN по мнгим параметрам интереснее. В твоем случае — не заморацивайся. Разве что ради интереса попробовать поюзать на каком-нибудь пилотном подпроекте.
Здравствуйте, Peregrin, Вы писали: P>Если вас всё устраивает, то может и не стоит. Но с другой стороны, у CVS нет никаких преимуществ перед SVN, а вот у SVN перед CVS полно.
[offtopic] Я работал только с CVS. SVN не знаю
Не подскажете преимущества SVN. Можно кратко и самые основные
Заранее благодарен
Здравствуйте, _vvs, Вы писали:
_>Здравствуйте, Peregrin, Вы писали: P>>Если вас всё устраивает, то может и не стоит. Но с другой стороны, у CVS нет никаких преимуществ перед SVN, а вот у SVN перед CVS полно.
_>[offtopic] Я работал только с CVS. SVN не знаю _>Не подскажете преимущества SVN. Можно кратко и самые основные
SVN позволяет сохранять историю изменений при переименовывании файлов. Для Java это может быть особенно полезно поскольку имена файлов связаны с именами классов (а каталогов с package'ами)
Здравствуйте, _vvs, Вы писали:
_>Здравствуйте, Peregrin, Вы писали: P>>Если вас всё устраивает, то может и не стоит. Но с другой стороны, у CVS нет никаких преимуществ перед SVN, а вот у SVN перед CVS полно.
_>[offtopic] Я работал только с CVS. SVN не знаю _>Не подскажете преимущества SVN. Можно кратко и самые основные _>Заранее благодарен
Атомарные операции (т.е. если не удаётся произвести операцию с одним файлом из группы операция откатывается и репозиторий не изменяется).
Очень быстрый таггинг/бранчинг (за константное время в не зависимости от количества файлов в репозитории).
Возможность переименования файлов и переноса в другие папки с сохранением истории.
Возможность смотреть локальные изменения и делать откаты на последнюю забранную версию без доступа к серверу, на котором находится репозиторий.
I>Стоит ли переходить с CVS на SVN и почему?
ИМХО, стОит.
Такой переход — это штатная ситуация, обкатан на большом количестве проектов и с довольно высокой вероятностью пройдёт практически безболезненно. При этом получаем все вкусности преимуществ SVN перед CVS — атомарность коммитов, отсутствие потерь history при переименовании файла, как одно из следствий — возможность "наводить порядок" в файловой структуре проекта не боясь ничего потерять, и многая многая других вкусностей.
Если бы переход осуществлялся с какой-нить экзотической VCS — тогда стоило бы ещё задуматься о его целесообразности в данный конкретный момент времени. Если это переход с CVS на SVN — есть смысл переходить как только найдётся чуть-чуть свободного времени, если проект живёт и развивается — то это время окупится очень быстро.
P>Атомарные операции (т.е. если не удаётся произвести операцию с одним файлом из группы операция откатывается и репозиторий не изменяется).
А чем тах уж хороши эти атомарные операции? Я за годы работы с CVS (в т.ч. с большими, проектами — такими, как ядро линуха) ни разу не нарывался на проблемы, связанные с неатомарностью коммитов.
Другое дело, что в CVS'е нет понятия многофайлового коммита. Ну так и в SVN'е его нет, одна видимость.
P>Возможность переименования файлов и переноса в другие папки с сохранением истории.
Нет у него rename. Есть copy и del, что ни одно и то же. Например, Вы не можете в одном коммите переименовать файл A в файл B, и сразу же файл C в файл A.
Здравствуйте, Pzz, Вы писали:
P>>Если вас всё устраивает, то может и не стоит. Но с другой стороны, у CVS нет никаких преимуществ перед SVN, а вот у SVN перед CVS полно.
Pzz>Насчет преимуществ. У SVN нет нормальных меток, в отличии от CVS.
Здравствуйте, Pzz, Вы писали:
P>>Атомарные операции (т.е. если не удаётся произвести операцию с одним файлом из группы операция откатывается и репозиторий не изменяется).
Pzz>А чем тах уж хороши эти атомарные операции? Я за годы работы с CVS (в т.ч. с большими, проектами — такими, как ядро линуха) ни разу не нарывался на проблемы, связанные с неатомарностью коммитов.
Они хороши тем, что они атомарные. Вы не сталкивались — значит Вам повезло, что я еще могу сказать. А я вот сталкивался с тем, что ставишь метку, связь рвется, половина файлов помечена, половина нет.
Pzz>Другое дело, что в CVS'е нет понятия многофайлового коммита. Ну так и в SVN'е его нет, одна видимость.
Поясните пожалуйста.
P>>Возможность переименования файлов и переноса в другие папки с сохранением истории.
Pzz>Нет у него rename. Есть copy и del, что ни одно и то же. Например, Вы не можете в одном коммите переименовать файл A в файл B, и сразу же файл C в файл A.
rename реализован с помощью copy и del, да, с тем только ньюансом, что история сохраняется. Я может и не могу (не пробовал ни разу, не приходилось) переименовать в SVN файл A в B и сразу же C в A, но Вы с CVS вообще их переименовывать не можете.
Здравствуйте, Peregrin, Вы писали:
Pzz>>Насчет преимуществ. У SVN нет нормальных меток, в отличии от CVS. P>Определите пожалуйста понятие "нормальная метка".
Слово метка — однокоренное со словом "метить". В CVS навешивание метки — это помечивание определной версии в дереве версий элемента. Т.е. живет себе версия, на неё можно спокойно навесить несколько меток, можно убрать... версия и файл остаются неизменными.
В SVN такой операции нет. Есть копирование множества элементов с выбранными версиями с сохранением информации об истории. Это почему-то гордо называется "меткой". Хотя, да, конечно, основную цель эта операция выполняет — т.е. позволяет выделить набор элементов с версиями.
A>В SVN такой операции нет. Есть копирование множества элементов с выбранными версиями с сохранением информации об истории. Это почему-то гордо называется "меткой". Хотя, да, конечно, основную цель эта операция выполняет — т.е. позволяет выделить набор элементов с версиями.
Да, только стоит отметить что копирование это не стоит ничего. Внутри базы копирования не происходит.
Вместо навешивания меток ты делаешь версии, застывшие в этом состоянии. Разница в идеологии есть, но привыкаешь к этому моментально. Кстати, мне подход SVN кажется более правильным — метки и бранчи суть одно и то же.
Pzz>А чем тах уж хороши эти атомарные операции? Я за годы работы с CVS (в т.ч. с большими, проектами — такими, как ядро линуха) ни разу не нарывался на проблемы, связанные с неатомарностью коммитов.
Самое первое что приходит в голову — система автобилда которая билдит проект и запускает юниттесты после каждого коммита. Как вариант (если билдить после каждого коммита слишком дорого) — автоматический поиск того человека коммит которого привёл к ошибкам в юниттестах. Как такое организовать в CVS?
Атомарность коммита позволяет иметь исходники всегда в состоянии "билдится и хоть как-то работает".
Pzz>Другое дело, что в CVS'е нет понятия многофайлового коммита. Ну так и в SVN'е его нет, одна видимость.
???
Абсолютно непонятно, почему это в SVN "одна видимость".
P>>Возможность переименования файлов и переноса в другие папки с сохранением истории. Pzz>Нет у него rename. Есть copy и del, что ни одно и то же. Например, Вы не можете в одном коммите переименовать файл A в файл B, и сразу же файл C в файл A.
Почему не могу? Только что попробовал, всё получилось. В любом случае, возможность переименовывать файлы с сохранением истории изменений — это фичер который есть в SVN и нет в CVS. Это позволяет в разы проще относится к перетасовке файлов внутри проекта, экономия времени налицо.
Похоже, тебе не нравится SVN тем что она неидеальна Да, она неидеальна — но она НАМНОГО ЛУЧШЕ CVS. И это повод чтобы сменить CVS на SVN.
Здравствуйте, Aquary, Вы писали:
A>Здравствуйте, Peregrin, Вы писали:
P>>Определите пожалуйста понятие "нормальная метка".
A>Слово метка — однокоренное со словом "метить". В CVS навешивание метки — это помечивание определной версии в дереве версий элемента. Т.е. живет себе версия, на неё можно спокойно навесить несколько меток, можно убрать... версия и файл остаются неизменными.
A>В SVN такой операции нет. Есть копирование множества элементов с выбранными версиями с сохранением информации об истории. Это почему-то гордо называется "меткой". Хотя, да, конечно, основную цель эта операция выполняет — т.е. позволяет выделить набор элементов с версиями.
На самом деле то "копирования" тоже нету Есть создание линка. Но это всё детали. Какая юзеру разница, как оно внутри реализовано, главное ведь, что функциональность присутствует.
Здравствуйте, Peregrin, Вы писали:
P>На самом деле то "копирования" тоже нету Есть создание линка. Но это всё детали. Какая юзеру разница, как оно внутри реализовано, главное ведь, что функциональность присутствует.
Согласен — главное, чтобы СМ можно было делать — мне, как СМщику это в конечном счете это главное . Просто я избалован ClearCase'ом
Здравствуйте, Left2, Вы писали:
L>Вместо навешивания меток ты делаешь версии, застывшие в этом состоянии. Разница в идеологии есть, но привыкаешь к этому моментально.
Да я привык давно, принял как данность, когда работаю с ним
L>Кстати, мне подход SVN кажется более правильным — метки и бранчи суть одно и то же.
Вот в том-то и дело, что в теории это — по сути своей — совершено разные вещи... То, что SVNовцы сделали именно так — считаю очень интересным проектным решением — действительно респект Однако правильным не могу назвать Я тут выше отписал, что избалован я "правильными" системами контроля версий
Это больше похоже общие вопросы программирования -> управление проектами
Есть создание линка. Но это всё детали. Какая юзеру разница, как оно внутри реализовано, главное ведь, что функциональность присутствует.
