Наша фирма уже более года работает с 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овцы сделали именно так — считаю очень интересным проектным решением — действительно респект Однако правильным не могу назвать Я тут выше отписал, что избалован я "правильными" системами контроля версий
L>>Кстати, мне подход SVN кажется более правильным — метки и бранчи суть одно и то же. A>Вот в том-то и дело, что в теории это — по сути своей — совершено разные вещи...
Хм. А в чём разница? В том что метки — это read-only бранчи?
Здравствуйте, Left2, Вы писали:
L>Да, только стоит отметить что копирование это не стоит ничего. Внутри базы копирования не происходит.
Черт с ним, с тем, сколько оно стоит. Я не про это.
Нормальная метка — это когда ты берешь историю какого-то файла, и видишь на нем метки, бранчи, слияния... В SVN'е же с файла делается копия куда-то в сторону. Получить из того, что в SVN'е называют "меткой" список относящихся к ней файлов легко. Но вот проделать обратную операцию — перейти от файла к меткам — крайне непросто.
Кстати, вот если взять какой-нибудь Perforce, там копирование дерева в стиле SVN мирно сосуществует с метками, и всему находится свое применение.
Здравствуйте, Peregrin, Вы писали:
P>Они хороши тем, что они атомарные. Вы не сталкивались — значит Вам повезло, что я еще могу сказать. А я вот сталкивался с тем, что ставишь метку, связь рвется, половина файлов помечена, половина нет.
Я не спорю с полезностью атомарных операций. Просто на мой взгляд они из серии nice feature, а не must have.
Проблема, о которой Вы рассказываете, вряд ли имела серьезные последствия. Вам всего-то и надо было, что переконнектиться, удалить недопоставленную метку, и поставить ее еще раз.
Pzz>>Другое дело, что в CVS'е нет понятия многофайлового коммита. Ну так и в SVN'е его нет, одна видимость.
P>Поясните пожалуйста.
Я хочу видеть commit (он же changeset), как объект, с которым можно проделать как минимум следующие операции:
1) Сослаться на него в разговоре с человеком
2) Получить список измененных файлов
3) Получить diff
В SVN'е такого объекта, как commit, нету. Вместо этого есть запись в логе под номером таким-то, и предлагается все остальное делать ручками, с помощью diff'а и знания этого номера.
P>>>Возможность переименования файлов и переноса в другие папки с сохранением истории.
P>rename реализован с помощью copy и del, да, с тем только ньюансом, что история сохраняется. Я может и не могу (не пробовал ни разу, не приходилось) переименовать в SVN файл A в B и сразу же C в A, но Вы с CVS вообще их переименовывать не можете.
Здравствуйте, Left2, Вы писали:
L>Самое первое что приходит в голову — система автобилда которая билдит проект и запускает юниттесты после каждого коммита. Как вариант (если билдить после каждого коммита слишком дорого) — автоматический поиск того человека коммит которого привёл к ошибкам в юниттестах. Как такое организовать в CVS? L>Атомарность коммита позволяет иметь исходники всегда в состоянии "билдится и хоть как-то работает".
В этом смысле CVS'овские коммиты тоже атомарны. CVS лочит дерево во время обновления. Насколько я понимаю, CVS не позволяет в середине операции выдернуть с соседнего компутера файлы в состоянии "половина до коммита, половина — после".
Другой вопрос, что если сам коммит по каким-то техническим причинам сломается (например, порвется связь, или CVS упадет на одной из сторон), то репозиторий может остаться в неконсистентном состоянии. Но лично я на такое не нарывался.
L>Абсолютно непонятно, почему это в SVN "одна видимость".
Я вольно или невольно сравниваю SVN'овские коммиты с коммитами в Perforce. Там коммит это некоторый самистоятельный объект, на который можно всячески посмотреть — например, в виде списка потроганных файлов или в виде diff'а. В SVN'е этого очень не хватает.
L>Почему не могу? Только что попробовал, всё получилось. В любом случае, возможность переименовывать файлы с сохранением истории изменений — это фичер который есть в SVN и нет в CVS. Это позволяет в разы проще относится к перетасовке файлов внутри проекта, экономия времени налицо.
Я как-то разок нарывался на то, как последовательность "переименований" привела SVN в состояние "не могу больше. Или коммить, как есть, или отвяжись". Пришлось закоммитеть как есть, хотя это в мои планы и не входило
L>Похоже, тебе не нравится SVN тем что она неидеальна Да, она неидеальна — но она НАМНОГО ЛУЧШЕ CVS. И это повод чтобы сменить CVS на SVN.
Я бы сказал, она НЕМНОГО лучше CVS
Мне очень мешает в SVN'е отсутствие бранчей и меток. Все остальное я мог бы стерпеть, но не это. Если бы мне пришлось вести в SVN'е порт ядра линуха на железку, я бы повесился (в CVS'е я это проделывал без особого напряга).
Здравствуйте, Left2, Вы писали: L>Хм. А в чём разница? В том что метки — это read-only бранчи?
Бранч — это ответвление дерева версий выбранного элемента; используется для параллельной разработки.
Метка — это выделение требуемой версии среди прочих по требуемому признаку; используется для определения бэйзлайна продукта.
Сравнивать метки и ветки — это как сравнивать столы и стулья... Да, на столах можно сидеть, а на стульях — раскладывать бутеброды... Но Есть лучше за столами, а сидеть при этом — на стульях.
Перенося на определения выше — можно выделять версию, отращивая специально под неё ветку. Можно и метки использовать, чтобы параллельно разрабатывать что-то... Вопрос — зачем?
Здравствуйте, Pzz, Вы писали:
Pzz>Но вот проделать обратную операцию — перейти от файла к меткам — крайне непросто.
Вот этого сильно не хватает, да... Стабильная версия какого-то файла может быть неизменной на протяжении долгого времени и входить в кучу меток (т.е. бэйзлайнов). В SVN нет тривиального способа сразу посмотреть, в какие бэйзлайны входила выбранная верси.
Pzz>В этом смысле CVS'овские коммиты тоже атомарны. CVS лочит дерево во время обновления. Насколько я понимаю, CVS не позволяет в середине операции выдернуть с соседнего компутера файлы в состоянии "половина до коммита, половина — после". Pzz>Другой вопрос, что если сам коммит по каким-то техническим причинам сломается (например, порвется связь, или CVS упадет на одной из сторон), то репозиторий может остаться в неконсистентном состоянии. Но лично я на такое не нарывался.
Я не об этом В CVS нет возможности различить границу между двумя последовательных многофайловыми коммитами. Из-за этого возможности иметь сорцы в состоянии "билдится и хоть как-то работает" сильно ограничены.
Pzz>Я вольно или невольно сравниваю SVN'овские коммиты с коммитами в Perforce. Там коммит это некоторый самистоятельный объект, на который можно всячески посмотреть — например, в виде списка потроганных файлов или в виде diff'а. В SVN'е этого очень не хватает.
Опять не понимаю. В SVN коммит — это самостоятельный обьект, который можно посмотреть в виде списка потроганных файлов или diff-a
Pzz>Я как-то разок нарывался на то, как последовательность "переименований" привела SVN в состояние "не могу больше. Или коммить, как есть, или отвяжись". Пришлось закоммитеть как есть, хотя это в мои планы и не входило
Э... Ну спишем это на баг конкретной реализации (кинь камнем у кого багов нету) и сойдёмся на том что переименования в SVN всё же есть
L>>Похоже, тебе не нравится SVN тем что она неидеальна Да, она неидеальна — но она НАМНОГО ЛУЧШЕ CVS. И это повод чтобы сменить CVS на SVN. Pzz>Я бы сказал, она НЕМНОГО лучше CVS
Ну практика показывает что 95% разработчиков которые переходили с CVS на SVN обратно возвращаться не хотели Тут как бы выбор между двумя бесплатными продуктами со схожим фичерсетом, один из которых современнее, поддерживает больше фичеров да и к тому же динамически развивается. Даже если переход с CVS на SVN даёт экономию в 10 минут в день на девелопера — я на месте PM-а постараюсь изыскать время на переезд с CVS на SVN. Заметь — я не рассматриваю тут более другие и как правило очень платные VCS.
Pzz>Мне очень мешает в SVN'е отсутствие бранчей и меток. Все остальное я мог бы стерпеть, но не это. Если бы мне пришлось вести в SVN'е порт ядра линуха на железку, я бы повесился (в CVS'е я это проделывал без особого напряга).
А ты расскажи зачем тебе при этом отдельно бранчи и отдельно метки. А то я пока не очень понимаю. Вот к примеру ACE/TAO — всем скопом переехали c CVS на SVN, довольны и счастливы. Хотя бы отказ от сопровождения текстовых файлов changelog даёт неслабую экономию времени на каждом коммите.
Здравствуйте, Pzz, Вы писали:
Pzz>Я вольно или невольно сравниваю SVN'овские коммиты с коммитами в Perforce. Там коммит это некоторый самистоятельный объект, на который можно всячески посмотреть — например, в виде списка потроганных файлов или в виде diff'а. В SVN'е этого очень не хватает.
Эээ... В SVN все точно так же — каждый коммит однозначно идентифицируется своим номером. По номеру коммита можно посмотреть список измененных файлов, взять diff этого коммита и т.п.
A>Бранч — это ответвление дерева версий выбранного элемента; используется для параллельной разработки. A>Метка — это выделение требуемой версии среди прочих по требуемому признаку; используется для определения бэйзлайна продукта.
Давай теперь посмотрим на это со стороны SVN. С бранчами всё понятно, они поддерживаются вроде как нативно. Для отслеживания бейзлайна продукта есть просто log. Каждый коммит атомарен, имеет свой номер и неизменен. Т.е. меткой является просто номер коммита — ВСЁ! Если хочешь каких-то специфичных меток для какой-то автоматизированных тулзов — их тоже можно организовать добавляя свои пропертя к коммитам.
Pzz>Черт с ним, с тем, сколько оно стоит. Я не про это. Pzz>Нормальная метка — это когда ты берешь историю какого-то файла, и видишь на нем метки, бранчи, слияния...
Ха! А если файл был переменован, к примеру? Или кусок из этого файла уехал в другой? Кстати, при наличии атомарного коммита можно написать скрипт который с большой вероятностью отследит путь куска исходников даже если они перекочёвывали из одного файла в другой. В CVS с этим будут проблемы.
Pzz>В SVN'е же с файла делается копия куда-то в сторону. Получить из того, что в SVN'е называют "меткой" список относящихся к ней файлов легко. Но вот проделать обратную операцию — перейти от файла к меткам — крайне непросто.
Элементарно делается — получаешь рутовый каталог репозитория и смотришь на нём полный лог. Там найдёшь ВСЁ что когда-либо делали с этим файлом.
Pzz>Кстати, вот если взять какой-нибудь Perforce, там копирование дерева в стиле SVN мирно сосуществует с метками, и всему находится свое применение.
Я к сожалению с Perforce не работал . Я в этой ветке пытаюсь убедить всех что SVN лучше CVS, а не то что SVN лучше всех
Здравствуйте, Pzz, Вы писали:
Pzz>Я не спорю с полезностью атомарных операций. Просто на мой взгляд они из серии nice feature, а не must have.
Pzz>Проблема, о которой Вы рассказываете, вряд ли имела серьезные последствия. Вам всего-то и надо было, что переконнектиться, удалить недопоставленную метку, и поставить ее еще раз.
Когда в дереве несколько десятков тысяч файлов, потагать это дерево — это задание не для слабонервных. Таг ставился более получаса при том, что CVS сервер находился в локалке. А Вы говорите удалить и поставить ещё раз.
Pzz>>>Другое дело, что в CVS'е нет понятия многофайлового коммита. Ну так и в SVN'е его нет, одна видимость.
P>>Поясните пожалуйста.
Pzz>Я хочу видеть commit (он же changeset), как объект, с которым можно проделать как минимум следующие операции: Pzz> 1) Сослаться на него в разговоре с человеком Pzz> 2) Получить список измененных файлов Pzz> 3) Получить diff
Pzz>В SVN'е такого объекта, как commit, нету. Вместо этого есть запись в логе под номером таким-то, и предлагается все остальное делать ручками, с помощью diff'а и знания этого номера.
1) На revision number можно сослаться в разговоре с человеком.
2) По revision number можно получить список измененных файлов.
3) По revision number можно получить diff с произвольным revision number, в том числе и с предыдущим.
Так что я не очень понял, чего Вам еще не хватает
Aquary wrote:
> Pzz>Но вот проделать обратную операцию — перейти от файла к меткам — > крайне непросто. > Вот этого сильно не хватает, да... Стабильная версия какого-то файла > может быть неизменной на протяжении долгого времени и входить в кучу > меток (т.е. бэйзлайнов). В SVN нет тривиального способа сразу > посмотреть, в какие бэйзлайны входила выбранная верси.
Revision Graph в tsvn? Работает безумно долго... но, вообще говоря, за
год использования мне никогда не потребовалось это, в отличие, скажем,
от переименования (которое нафиг порушит в cvs все связи от файла к меткам).
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, irbis81, Вы писали:
I>Наша фирма уже более года работает с CVS. I>В принципе нас всё устраивает. I>Я слышал что многие переходят с CVS на SVN. I>Стоит ли переходить с CVS на SVN и почему?
I>Заранее благодарен за ответ.
Посмотрите в Google по "CVS vs SVN". Масса материала по теме.
Вот, например, один из первых результатов в выдаче:
Здравствуйте, Peregrin, Вы писали:
Pzz>>Проблема, о которой Вы рассказываете, вряд ли имела серьезные последствия. Вам всего-то и надо было, что переконнектиться, удалить недопоставленную метку, и поставить ее еще раз.
P>Когда в дереве несколько десятков тысяч файлов, потагать это дерево — это задание не для слабонервных. Таг ставился более получаса при том, что CVS сервер находился в локалке. А Вы говорите удалить и поставить ещё раз.
Да, я в курсе. Говорю же, я в CVS'е ядро линуха ковырял. Запускаешь cvs tag, и идешь обедать
И тем не менее, Вы путаете 2 разные фичи: быстрые метки и атомарные коммиты.
Pzz>>В SVN'е такого объекта, как commit, нету. Вместо этого есть запись в логе под номером таким-то, и предлагается все остальное делать ручками, с помощью diff'а и знания этого номера.
P>1) На revision number можно сослаться в разговоре с человеком. P>2) По revision number можно получить список измененных файлов. P>3) По revision number можно получить diff с произвольным revision number, в том числе и с предыдущим. P>Так что я не очень понял, чего Вам еще не хватает
Вам надо как-нибудь посмотреть, как работают changeset'ы там, где они есть. Например в Perforce. Тогда Вы поймете, о чем я говорю
Здравствуйте, ., Вы писали:
.>Revision Graph в tsvn? Работает безумно долго... но, вообще говоря, за .>год использования мне никогда не потребовалось это, в отличие, скажем, .>от переименования (которое нафиг порушит в cvs все связи от файла к меткам).
В новых бэтах TSVN они кэшируют log entries, так что оно может и ускорится.
Здравствуйте, Pzz, Вы писали:
Pzz>Вам надо как-нибудь посмотреть, как работают changeset'ы там, где они есть. Например в Perforce. Тогда Вы поймете, о чем я говорю
В SVN changeset'ом является каждый коммит. В принципе, этого вполне достаточно.
Ну а скоро еще и умный merging подоспеет — так вообще жизнь станет еще лучше.
Здравствуйте, Left2, Вы писали:
L>Я не об этом В CVS нет возможности различить границу между двумя последовательных многофайловыми коммитами. Из-за этого возможности иметь сорцы в состоянии "билдится и хоть как-то работает" сильно ограничены.
Ну раз многочисленные конвертилки из CVS во что-то другое умеют эти многофайловые коммиты выделять, то наверное все-таки есть. Другой вопрос, что в пользовательском интерфейсе CVS'а они очевидным образом не представлены.
Тем не менее, я не очень понимаю, каким образом многофайловые коммиты помогают держать сорсы в состоянии "билдится и хоть как-то работает". По-моему, это зависит только от аккуратности тех кто коммитит. Впрочем, да, есть таки фича, которая помогает: возможность для девелопера создавать свои личные бранчи на эту вот конкретную работу, а потом сливать их в основную ветку.
Pzz>>Я вольно или невольно сравниваю SVN'овские коммиты с коммитами в Perforce. Там коммит это некоторый самистоятельный объект, на который можно всячески посмотреть — например, в виде списка потроганных файлов или в виде diff'а. В SVN'е этого очень не хватает. L>Опять не понимаю. В SVN коммит — это самостоятельный обьект, который можно посмотреть в виде списка потроганных файлов или diff-a
В SVN существует способ вычислить, какие именно файлы затронуты данным конкретным коммитом. Причем корректность ответа зависит от того, правильно ли указано, от какого места в дереве делать это вычисление (сколько раз я ошибался, получая список файлов от текущей директории, а не от корня!). Да и сами вычисления, насколько я помню, не быстрые. Не помню, есть ли способ получить именно список файлов, а не diff. Кажется, нет, но могу ошибаться, т.к. с SVN'ом давно не работал.
В P4 же коммит это объект, который (я не про имлементацию, до которой мне нет дела, а про то, как это представлено в пользовательском интерфейсе) не вычислается по запросу, а просто существует в природе.
Я уже не говорю о том, что в P4 commit как объект создается еще до того, как что-либо закинуто в репозиторий. И уже в этот момент с ним можно делать всякие полезные штуки. Например, поредактировать log message, разбить его на 2 коммита и т.п.
Pzz>>Я как-то разок нарывался на то, как последовательность "переименований" привела SVN в состояние "не могу больше. Или коммить, как есть, или отвяжись". Пришлось закоммитеть как есть, хотя это в мои планы и не входило L>Э... Ну спишем это на баг конкретной реализации (кинь камнем у кого багов нету) и сойдёмся на том что переименования в SVN всё же есть
И все-таки нету. При копировании я получаю новый объект, со своей собственной историей и т.п. При переименовании объект должен оставаться тем же, только под другим именем.
L>Ну практика показывает что 95% разработчиков которые переходили с CVS на SVN обратно возвращаться не хотели Тут как бы выбор между двумя бесплатными продуктами со схожим фичерсетом, один из которых современнее, поддерживает больше фичеров да и к тому же динамически развивается. Даже если переход с CVS на SVN даёт экономию в 10 минут в день на девелопера — я на месте PM-а постараюсь изыскать время на переезд с CVS на SVN. Заметь — я не рассматриваю тут более другие и как правило очень платные VCS.
Напоминает анекдот:
— скажите, Вы кем работаете?
— да укладчиком парашютов
— должно быть, ответственная работа?
— да никто пока не жаловался!
Я бы обратил внимание на современные, и тем не менее, бесплатные VCS'ы типа Меркурия, Git'а, Базара...
Я думаю, будущее именно за ними, а SVN, частично решая проблемы CVS'а, только лишь лежит бревном на рельсах прогресса
Pzz>>Мне очень мешает в SVN'е отсутствие бранчей и меток. Все остальное я мог бы стерпеть, но не это. Если бы мне пришлось вести в SVN'е порт ядра линуха на железку, я бы повесился (в CVS'е я это проделывал без особого напряга). L>А ты расскажи зачем тебе при этом отдельно бранчи и отдельно метки. А то я пока не очень понимаю. Вот к примеру ACE/TAO — всем скопом переехали c CVS на SVN, довольны и счастливы. Хотя бы отказ от сопровождения текстовых файлов changelog даёт неслабую экономию времени на каждом коммите.
Дык эта, в SVN'е-то нет ни бранчей, ни веток, об чем я и талдычу все это время.
Просто сравни процедуры работы с vendor branch'ами в CVS и SVN, и все станет сразу понятно...
Здравствуйте, Left2, Вы писали:
Pzz>>Черт с ним, с тем, сколько оно стоит. Я не про это. Pzz>>Нормальная метка — это когда ты берешь историю какого-то файла, и видишь на нем метки, бранчи, слияния... L>Ха! А если файл был переменован, к примеру? Или кусок из этого файла уехал в другой? Кстати, при наличии атомарного коммита можно написать скрипт который с большой вероятностью отследит путь куска исходников даже если они перекочёвывали из одного файла в другой. В CVS с этим будут проблемы.
Это одно из мест, где true renames отличаются от copy + del. Переименование это операция над директорией, а не над файлом. Т.е., если файл меняет имя, то в истории файла меточка остается, но в истории директории новое имя оказывается выше меточки.
Это позвляет, в частности, посмотреть diff между 2-мя метками на файле, даже если файл переименовывался в процесее, без необходимости угадывать его старое имя — фича, совершенно отсутствующая в SVN'е.
Pzz>>Кстати, вот если взять какой-нибудь Perforce, там копирование дерева в стиле SVN мирно сосуществует с метками, и всему находится свое применение. L>Я к сожалению с Perforce не работал . Я в этой ветке пытаюсь убедить всех что SVN лучше CVS, а не то что SVN лучше всех
Интереснее говорить о SVN'е (и и других системах контроля версий) вообще, а не сравнивать SVN с CVS'ом.
Здравствуйте, Pzz, Вы писали:
Pzz>Да, я в курсе. Говорю же, я в CVS'е ядро линуха ковырял. Запускаешь cvs tag, и идешь обедать
Pzz>И тем не менее, Вы путаете 2 разные фичи: быстрые метки и атомарные коммиты.
Быстрые метки и атомарные операции (началось то всё с неатомарности установки метки в цвс) — я их не путаю, просто это 2 преимущества (для меня) SVN перед CVS
Pzz>Вам надо как-нибудь посмотреть, как работают changeset'ы там, где они есть. Например в Perforce. Тогда Вы поймете, о чем я говорю
Я игрался немного с Perforce. Ну не вижу я отличий SVN revision'a от Perforce changlist'a
Pzz wrote:
> L>Я не об этом В CVS нет возможности различить границу между двумя > последовательных многофайловыми коммитами. Из-за этого возможности иметь > сорцы в состоянии "билдится и хоть как-то работает" сильно ограничены. > Ну раз многочисленные конвертилки из CVS во что-то другое умеют эти > многофайловые коммиты выделять, то наверное все-таки есть. Другой > вопрос, что в пользовательском интерфейсе CVS'а они очевидным образом не > представлены.
Они там предполагаются, т.е. по разнице времени, близости и т.п. Т.е.
если время между коммитами меньше 5 сек, да от одного юзера, то скорее
всего это был один коммит...
> Тем не менее, я не очень понимаю, каким образом многофайловые коммиты > помогают держать сорсы в состоянии "билдится и хоть как-то работает". > По-моему, это зависит только от аккуратности тех кто коммитит. Впрочем, > да, есть таки фича, которая помогает: возможность для девелопера > создавать свои личные бранчи на эту вот конкретную работу, а потом > сливать их в основную ветку.
Коммитишь 20 файлов. 18 закоммитилось, а 2 последних — не up-to-date —
облом. Пока апдейтишь, резолвишь кофликты — у других юзеров может всё
поломаться. svn же откатит всё.
> Pzz>>Я вольно или невольно сравниваю SVN'овские коммиты с коммитами в > Perforce. Там коммит это некоторый самистоятельный объект, на который > можно всячески посмотреть — например, в виде списка потроганных файлов > или в виде diff'а. В SVN'е этого очень не хватает. > L>Опять не понимаю. В SVN коммит — это самостоятельный обьект, который > можно посмотреть в виде списка потроганных файлов или diff-a > В SVN существует способ *вычислить*, какие именно файлы затронуты данным > конкретным коммитом. Причем корректность ответа зависит от того, > правильно ли указано, от какого места в дереве делать это вычисление > (сколько раз я ошибался, получая список файлов от текущей директории, а > не от корня!). Да и сами вычисления, насколько я помню, не быстрые. Не > помню, есть ли способ получить именно список файлов, а не diff. Кажется, > нет, но могу ошибаться, т.к. с SVN'ом давно не работал.
Ошибаешься. Скажем, tsvn показывает список всех файлов, притом если ты
"не в корне", то не попавшие файлы просто серым показываютя (или не
показываются вообще, если галочка не стоит).
> В P4 же коммит это объект, который (я не про имлементацию, до которой > мне нет дела, а про то, как это представлено в пользовательском > интерфейсе) не вычислается по запросу, а просто существует в природе.
В svn тоже появляется в ифейсе. И именно объект, притом транзакционный.
> Я уже не говорю о том, что в P4 commit как объект создается еще до того,
Как в p4 он идентифицируется?
> как что-либо закинуто в репозиторий. И уже в этот момент с ним можно > делать всякие полезные штуки. Например, поредактировать log message, > разбить его на 2 коммита и т.п.
log message можно редактировать (если прав достаточно). А вот
разбивать?.. Зачем?
> Pzz>>Я как-то разок нарывался на то, как последовательность > "переименований" привела SVN в состояние "не могу больше. Или коммить, > как есть, или отвяжись". Пришлось закоммитеть как есть, хотя это в мои > планы и не входило > L>Э... Ну спишем это на баг конкретной реализации (кинь камнем у кого > багов нету) и сойдёмся на том что переименования в SVN всё же есть > И все-таки нету. При копировании я получаю новый объект, со своей > собственной историей и т.п. При переименовании объект должен оставаться > тем же, только под другим именем.
История не собственная, она тоже копируется, точнее первой точкой истоии
становится "скопированно из <url> ревизия <nnn>". Начало историй будет
одним и тем же. А продолжение — естественно разное. Переименование — то
же копирование, но с удалением оригинала.
> Дык эта, в SVN'е-то нет ни бранчей, ни веток, об чем я и талдычу все это > время.
Тсс!.. А то люди не знают и благополучно используют.
> Просто сравни процедуры работы с vendor branch'ами в CVS и SVN, и все > станет сразу понятно...
Да тоже самое, только в svn попроще этим пользоваться и поэффективнее
работает.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[10]: Стоит ли переходить с CVS на SVN и почему?
Здравствуйте, Left2, Вы писали:
L> Для отслеживания бейзлайна продукта есть просто log. Каждый коммит атомарен, имеет свой номер и неизменен. Т.е. меткой является просто номер коммита — ВСЁ!
Отслеживание бэйзлайна — эт как? Бэйзлайн — это множество элементов с выбранными версиями, которые считаются стабильными. Бэйзлайны идентифицируются созданием метки — т.е. помечиванием этих самых элементов и выбраным версий каким-либо способом. Возможно, ты имел в виду идентификацию?
В SVN же идентификация бэйзлайна заключается в том, что в отдельное место — папку с определеннвм названием — копируются дирки и файлы выбранной ревизии.
А насчет того, чтобы ревизию называть меткой — ты погорячился Принято метку делать уникальным символьным обозначением бэйзлайна. Номер для этой цели мало подходит Сравни rev240, rev241 и COMPONENT_FOO_2.1, SUBSYSTEM_BAR_0.1. Буквы как-то проще воспринимаются
Здравствуйте, Cyberax, Вы писали:
Pzz>>Вам надо как-нибудь посмотреть, как работают changeset'ы там, где они есть. Например в Perforce. Тогда Вы поймете, о чем я говорю C>В SVN changeset'ом является каждый коммит. В принципе, этого вполне достаточно.
diff, patch, e-mail и немного шелловских скриптов тоже в принципе вполне достаточно
Source control добавляет к этому определенные удобства.
C>Ну а скоро еще и умный merging подоспеет — так вообще жизнь станет еще лучше.
Это который при следующем merge учитывает changes, уже замерженные раньше? Давно пора, кстати.
Re[11]: Стоит ли переходить с CVS на SVN и почему?
Aquary wrote:
> А насчет того, чтобы ревизию называть меткой — ты погорячился Принято > метку делать уникальным символьным обозначением бэйзлайна. Номер для > этой цели мало подходит Сравни rev240, rev241 и COMPONENT_FOO_2.1, > SUBSYSTEM_BAR_0.1. Буквы как-то проще воспринимаются
А чем не нравится
> В SVN же идентификация бэйзлайна заключается в том, что в отдельное
> место — папку с определеннвм названием — копируются дирки и файлы
> выбранной ревизии.
?
Ведь если ты не знал, то копировать можно в самом репозитории, не делая
реальные копии где-либо. А потом, при необходимости, делать switch, при
этом апдейтиться будут только различающиеся файлы.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Pzz wrote:
> Это одно из мест, где true renames отличаются от copy + del. > Переименование это операция над директорией, а не над файлом. Т.е., если > файл меняет имя, то в истории файла меточка остается, но в истории > директории новое имя оказывается выше меточки. > > Это позвляет, в частности, посмотреть diff между 2-мя метками на файле, > даже если файл переименовывался в процесее, без необходимости угадывать > его старое имя — фича, совершенно отсутствующая в SVN'е.
Присутствует, по крайней мере в tsvn. Просто надо галочку убрать "Stop
on copy/rename", которая по умолчанию поставлена.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[10]: Стоит ли переходить с CVS на SVN и почему?
Здравствуйте, ., Вы писали:
.>Коммитишь 20 файлов. 18 закоммитилось, а 2 последних — не up-to-date — .>облом. Пока апдейтишь, резолвишь кофликты — у других юзеров может всё .>поломаться. svn же откатит всё.
Это я понимаю. Однако это маловероятная катастрофа. Т.е., если мне пытаются это продавать, как основное преимущество SVN перед CVS и мне захочется пофлеймить, я на это отвечу в том духе, что зато у CVS'а весь репозиторий — текстовые файлы. Если у SVN'а разнесет репозиторий, его уже хрен починишь, а с CVS'ом шансов намного больше.
Если серьезно, я предлагаю сравнивать разные системы контроля версий с точки зрения той концептуальной модели, в которой построен пользовательский интерфейс, а не с точки зрения деталей имплементации. Так вот, на мой взгляд атомарность коммитов это именно детали имплементации. Концептуальное отличие — это когда многофайловый коммит виден пользователю как нечто единое целое (не в случае аварии, а в нормальной жизни). В SVN'е это есть, но сделано достаточно по-детски.
Обидно причем, что эта недоделанность SVN'овских коммитов, это сознательная позиция авторов, а не просто недоделка.
>> L>Опять не понимаю. В SVN коммит — это самостоятельный обьект, который >> можно посмотреть в виде списка потроганных файлов или diff-a
Хорошо, спрошу по другому. Если коммит в SVN'е это самостоятельный объект, каким интерфейсом обладает этот объект?
.>Ошибаешься. Скажем, tsvn показывает список всех файлов, притом если ты .>"не в корне", то не попавшие файлы просто серым показываютя (или не .>показываются вообще, если галочка не стоит).
tsvn это надстройка, которая добавляет к SVN'у от себя. Я говорю о SVN'е, а не об настройках над ним. В частности потому, tsvn живет в виндовой гуйне, а я — в линуксячей командной строке.
>> Я уже не говорю о том, что в P4 commit как объект создается еще до того, .>Как в p4 он идентифицируется?
Номером. Тот, который существует только на клиентской машинке, по-моему называется default. Могу ошибиться — давно уж не работал с P4.
.>log message можно редактировать (если прав достаточно). А вот .>разбивать?.. Зачем?
Очень часто решая какую-то конкретную проблему, делаешь на самом деле 2 вещи:
1) Создаешь инфраструктуру для решения этой и подобных проблем
2) Решаешь ту проблему, ради которой это все и затевалось
На мой взгляд, значительно удобнее, когда это проходит несколькими change'ми по source control'у — при условии, что каждый change сам по себе логически самодостаточен. Можно, конечно, сначала создать инфраструктуру, засубмиттить, решить проблему, засубмиттить. Но удобнее создать инфраструктуру, решить проблему, параллельно обкатав новую инфраструктуру в плане ее usability, а потом засубмиттить и то и другое отдельными commit'ами.
.>История не собственная, она тоже копируется, точнее первой точкой истоии .>становится "скопированно из <url> ревизия <nnn>". Начало историй будет .>одним и тем же. А продолжение — естественно разное. Переименование — то .>же копирование, но с удалением оригинала.
Переименование это назначение нового имени старому объекту. Копирование это создание нового объекта. Это 2 разные операции.
>> Просто сравни процедуры работы с vendor branch'ами в CVS и SVN, и все >> станет сразу понятно... .>Да тоже самое, только в svn попроще этим пользоваться и поэффективнее .>работает.
Здравствуйте, Pzz, Вы писали:
Pzz>Это я понимаю. Однако это маловероятная катастрофа. Т.е., если мне пытаются это продавать, как основное преимущество SVN перед CVS и мне захочется пофлеймить, я на это отвечу в том духе, что зато у CVS'а весь репозиторий — текстовые файлы. Если у SVN'а разнесет репозиторий, его уже хрен починишь, а с CVS'ом шансов намного больше.
Разнести fsfs-репозиторий в SVN очень сложно — так как файлы с ревизиями иммутабельны (посмотри как-нибудь как файлы репозитория в SVN выглядят).
Pzz>Обидно причем, что эта недоделанность SVN'овских коммитов, это сознательная позиция авторов, а не просто недоделка.
Я видел changeset'ы в Perforce. Приятно, но особого смысла в них я не вижу.
Pzz>Хорошо, спрошу по другому. Если коммит в SVN'е это самостоятельный объект, каким интерфейсом обладает этот объект?
Можно взять список изменений, сделать обратный merge этих изменений, посмотреть метаданные и т.п.
Собственно, для этого в SVN есть официальный API с байндингами к туче языков.
Pzz>tsvn это надстройка, которая добавляет к SVN'у от себя. Я говорю о SVN'е, а не об настройках над ним. В частности потому, tsvn живет в виндовой гуйне, а я — в линуксячей командной строке.
TSvn ничего практически не добавляет — это просто клиент для SVN. Все что можно сделать в TSvn (кроме разве что графа ревизий) можно сделать и в командной строке, просто это будет не так удобно.
Pzz>На мой взгляд, значительно удобнее, когда это проходит несколькими change'ми по source control'у — при условии, что каждый change сам по себе логически самодостаточен. Можно, конечно, сначала создать инфраструктуру, засубмиттить, решить проблему, засубмиттить. Но удобнее создать инфраструктуру, решить проблему, параллельно обкатав новую инфраструктуру в плане ее usability, а потом засубмиттить и то и другое отдельными commit'ами.
Это будет в SVN 1.5: поддержка клиентских changeset'ов: http://blogs.open.collab.net/svn/2007/05/the_subversion__1.html
Pzz>Поэффективнее работает копирование дерева. Merge работает так же, и делает примерно то же. Насчет поудобнее, мне лично удобнее писать метку вида LINUX_2_4_20, чем http://mysvn.mycompany.com/mydepartment/myproject/vendor/linux.2.4.20 Pzz>Причем "пути" в SVN'е становятся особенно эротичными, когда компания большая и проектов много.
Ага, а в CVS эротики добавляет невозможность отменить создания ветки. Поэтому годами живут названия типа PRENT_PREVIEW_BRANCH.
Sapienti sat!
Re[11]: Стоит ли переходить с CVS на SVN и почему?
Здравствуйте, Pzz, Вы писали:
C>>В SVN changeset'ом является каждый коммит. В принципе, этого вполне достаточно. Pzz>diff, patch, e-mail и немного шелловских скриптов тоже в принципе вполне достаточно
Ну да, добавить пару скриптов — и получится GIT.
Pzz>Source control добавляет к этому определенные удобства.
Именно.
C>>Ну а скоро еще и умный merging подоспеет — так вообще жизнь станет еще лучше. Pzz>Это который при следующем merge учитывает changes, уже замерженные раньше? Давно пора, кстати.
Ага, с возможность делать cherry picking и т.п.
I>Наша фирма уже более года работает с CVS. I>В принципе нас всё устраивает. I>Я слышал что многие переходят с CVS на SVN. I>Стоит ли переходить с CVS на SVN и почему?
Однозначно стоит. Причина — на порядок более технологичное решение. О плюсах — написано на самой странице проекта. Добавлю ещё, что в 1.5 версии, которая должна скоро зарелизиться будет добавлена мега полезная фича, merge tracking.
Народная мудрось
всем все никому ничего(с).
Re[11]: Стоит ли переходить с CVS на SVN и почему?
Pzz wrote:
> .>Коммитишь 20 файлов. 18 закоммитилось, а 2 последних — не up-to-date — > .>облом. Пока апдейтишь, резолвишь кофликты — у других юзеров может всё > .>поломаться. svn же откатит всё. > Это я понимаю. Однако это маловероятная катастрофа. Т.е., если мне > пытаются это продавать, как основное преимущество SVN перед CVS и мне > захочется пофлеймить, я на это отвечу в том духе, что зато у CVS'а весь > репозиторий — текстовые файлы. Если у SVN'а разнесет репозиторий, его > уже хрен починишь, а с CVS'ом шансов намного больше.
Кибер объяснил, убить SVN репозиторий гораздо сложнее. Да и вообще
говоря, надееться на текстовость формата при сбоях — наивно.
> Если серьезно, я предлагаю сравнивать разные системы контроля версий с > точки зрения той концептуальной модели, в которой построен > пользовательский интерфейс, а не с точки зрения деталей имплементации.
У svn нет как такового пользовательского интерфейса, есть фактически
только API, и дефолтный command-line клиент. А пользовательских
интерфейсов у него не менее десятка.
> Так вот, на мой взгляд атомарность коммитов это именно детали > имплементации. Концептуальное отличие — это когда многофайловый коммит > *виден пользователю* как нечто единое целое (не в случае аварии, а в > нормальной жизни). В SVN'е это есть, но сделано достаточно по-детски.
Мне виден. Погляди внимательнее, может и ты увидишь.
>> > L>Опять не понимаю. В SVN коммит — это самостоятельный обьект, который >> > можно посмотреть в виде списка потроганных файлов или diff-a > Хорошо, спрошу по другому. Если коммит в SVN'е это самостоятельный > объект, каким интерфейсом обладает этот объект?
У него есть идентификатор, можно узнать log message, поменять его,
owner, timestamp, с ним можно мержиться, диффаться, его можно чекаутить,
свитчить и т.п.
> .>Ошибаешься. Скажем, tsvn показывает список всех файлов, притом если ты > .>"не в корне", то не попавшие файлы просто серым показываютя (или не > .>показываются вообще, если галочка не стоит). > tsvn это надстройка, которая добавляет к SVN'у от себя. Я говорю о > SVN'е, а не об настройках над ним. В частности потому, tsvn живет в > виндовой гуйне, а я — в линуксячей командной строке.
Это не надстройка, а gui-интерфейс, фактически делающий одно —
формирующий с помощью мышки командную строку.
>> > Я уже не говорю о том, что в P4 commit как объект создается еще до того, > .>Как в p4 он идентифицируется? > Номером. Тот, который существует только на клиентской машинке, по-моему > называется default. Могу ошибиться — давно уж не работал с P4.
В svn тоже номер. А он последовательный? Если так, то как разбиение
коммита работает?
> .>log message можно редактировать (если прав достаточно). А вот > .>разбивать?.. Зачем? > > Очень часто решая какую-то конкретную проблему, делаешь на самом деле 2 > вещи: > 1) Создаешь инфраструктуру для решения этой и подобных проблем > 2) Решаешь ту проблему, ради которой это все и затевалось > > На мой взгляд, значительно удобнее, когда это проходит несколькими > change'ми по source control'у — при условии, что каждый change сам по > себе логически самодостаточен. Можно, конечно, сначала создать > инфраструктуру, засубмиттить, решить проблему, засубмиттить. Но удобнее > создать инфраструктуру, решить проблему, параллельно обкатав новую > инфраструктуру в плане ее usability, а потом засубмиттить и то и другое > отдельными commit'ами.
Дык коммить несколько раз... кто запрещает? Просто если ты уже
закоммитил, то "раскоммитить" уже нельзя, чтобы перекоммитить
скомбинировав по-другому... Точнее можно, но это останется в истории.
> .>История не собственная, она тоже копируется, точнее первой точкой истоии > .>становится "скопированно из <url> ревизия <nnn>". Начало историй будет > .>одним и тем же. А продолжение — естественно разное. Переименование — то > .>же копирование, но с удалением оригинала. > Переименование это назначение нового имени старому объекту. Копирование > это создание нового объекта. Это 2 разные операции.
Ты яву знаешь? Вот представь себе, что ревизия это имя переменной, все
переменные final, а объект — он "где-то там".
final Object rev123 = new Object();
final Object branch1 = rev123;
Так что в svn объекты новые не создаются при копировании, а просто
создаются ссылки на них.
>> > Просто сравни процедуры работы с vendor branch'ами в CVS и SVN, и все >> > станет сразу понятно... > .>Да тоже самое, только в svn попроще этим пользоваться и поэффективнее > .>работает. > Поэффективнее работает копирование дерева. Merge работает так же, и > делает примерно то же. Насчет поудобнее, мне лично удобнее писать метку > вида LINUX_2_4_20, чем > http://mysvn.mycompany.com/mydepartment/myproject/vendor/linux.2.4.20 > Причем "пути" в SVN'е становятся особенно эротичными, когда компания > большая и проектов много.
Мелочи. Элементарно решается адекватным ui.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>Revision Graph в tsvn? Работает безумно долго...
Заметь — это не нативное решение, а надстройка... Ядро системы не позволяет этого делать простыми движениями
.>но, вообще говоря, за год использования мне никогда не потребовалось это,
А вот у меня такое — каждый день Проект крупный, отслеживание веток, меток, мержей — каждодневная рутина.
.>в отличие, скажем, от переименования (которое нафиг порушит в cvs все связи от файла к меткам).
Вот это уже вопрос к зрелости проекта и вообще проектированию... что это за проект, где файлы часто переименовываются?
Здравствуйте, ., Вы писали:
.>А чем не нравится .>
...
.>? .>Ведь если ты не знал, то копировать можно в самом репозитории, не делая .>реальные копии где-либо. А потом, при необходимости, делать switch, при .>этом апдейтиться будут только различающиеся файлы.
Не нравится тем, что я не хочу иметь отдельную папку с тем, что посчитали бэйзлайном. Пусть даже в репозитории, пусть даже это фактически это линк и место никак не отъедается. Во других системах контроля версий у тебя есть дерево файлов, к каждому из которых привязано дерево версий. Т.е существует как бы 2 измерения, в каждом из которых ты работаешь в зависимости от потребностей. При необходимости эти измерения "встречаются", однако элемент и их дерево версий — разделены принципиально. В SVN же всё сводится к новым папкам.
Я уже говорил, что это классное проектное решение — всё свести к папкам, всё становится более единообразно... однако есть случаи когда это мешает. Пример уже приводили — в "чистом" SVN, без надстроек и скриптов, по взятому файлу из транка нельзя сказать — в какие метки он вошел, откуда были сделаны мержи.
Вот пример. Сколько приседаний займет в SVN подобная картина (речь для простоты об одном файле из множества имеющися):
— выпущен бэйзлайн, он прошел тесты и считается стабильным,
— есть проблема Х, для решения от бэйзлайна отрастили девелоперский бранч, частично решили на своем бранче,
— одновременно фиксят баг Y, решение опирается на фикс проблемы X.
— фикс Х интегрируют в бэйзлайн, в котором к тому времени уже обновился другими фиксами
— фикс Y перемерживают на новый бэйзлайн, дорабатывают "косметику", интегрируют в следующиую версию бэйзлайна.
Ответьте, апологеты SVN — вы не за%%%тесь проследить подобную картину только по дереву версий? Без tsvn, а просто силами ядра системы? В CVS, не говоря уже о ClearCase и P4 достаточно взять один элемент и сделать описание файла или версии — там всё будет как на ладони, все отращивания/мержи. Для того, чтобы сравнить изменения, отслеждить пути изменений файла — не надо будет скакать между виртуальными директориями АКА ветками, все операции делаются с одним файлом, лежащим во всё то же дирке.
Уверен, вы найдете способы решить описанную задачу, однако сколько усилий вы потратите?
Здравствуйте, ., Вы писали:
.>У svn нет как такового пользовательского интерфейса, есть фактически .>только API, и дефолтный command-line клиент. А пользовательских .>интерфейсов у него не менее десятка.
Очень убедительный аргумент. В таком случае, POSIX API — лучшая система контроля версий в мире. Ведь из нее можбо сделать любую другую
>> Номером. Тот, который существует только на клиентской машинке, по-моему >> называется default. Могу ошибиться — давно уж не работал с P4. .>В svn тоже номер. А он последовательный? Если так, то как разбиение .>коммита работает?
Разбить можно еще непосубмиченный коммит.
>> Переименование это назначение нового имени старому объекту. Копирование >> это создание нового объекта. Это 2 разные операции. .>Ты яву знаешь? Вот представь себе, что ревизия это имя переменной, все .>переменные final, а объект — он "где-то там".
Мы не обсуждаем сейчас, как SVN устроен внутри. Современный UNIX при fork()'е тоже ничего не копирует, однако семантика fork'а — создание копии процесса. Вот и семантика svn copy — создание копии объекта, а не действие с именем.
То, что внутри SVN'а copy обходится без копирования, это детали реализации.
>> делает примерно то же. Насчет поудобнее, мне лично удобнее писать метку >> вида LINUX_2_4_20, чем >> http://mysvn.mycompany.com/mydepartment/myproject/vendor/linux.2.4.20 >> Причем "пути" в SVN'е становятся особенно эротичными, когда компания >> большая и проектов много. .>Мелочи. Элементарно решается адекватным ui.
Мы не обсуждаем, что с помощью кирки, лопаты и какой-то матери из SVN'а можно таки сделать нормальный продукт. Как я уже заметил выше, нормальный продукт можно сделать из голого POSIX API. Мы сейчас обсуждаем SVN как продукт.
Re[10]: Стоит ли переходить с CVS на SVN и почему?
Здравствуйте, Aquary, Вы писали:
.>>в отличие, скажем, от переименования (которое нафиг порушит в cvs все связи от файла к меткам). A>Вот это уже вопрос к зрелости проекта и вообще проектированию... что это за проект, где файлы часто переименовываются?
Очень странное замечание.
1. Только убожеством системы контроля версий можно оправдать исскуственное ограничение на (не)переименовывание файлов
2. Возможно это делается и не часто, но иногда бывает нужно в любом проекте.
3. А незрелым проектам так вообще получается не стоит жить в CVS, пока не дорастут
Re[11]: Стоит ли переходить с CVS на SVN и почему?
Здравствуйте, Константин, Вы писали:
К>Очень странное замечание. К>1. Только убожеством системы контроля версий можно оправдать исскуственное ограничение на (не)переименовывание файлов
Я и не говорил, что раз в CVS этого нет, то и не надо просто это так сильно превозносят поклонники SVN, как будто это самая главая фича любой системы контроля версий
К>2. Возможно это делается и не часто, но иногда бывает нужно в любом проекте.
Вот и отлично, что есть. Но и безпереименования жить можно неплохо
К>3. А незрелым проектам так вообще получается не стоит жить в CVS, пока не дорастут
Вот этого я не говорил перегибаешь...
Aquary wrote:
> Не нравится тем, что я не хочу иметь отдельную папку с тем, что > посчитали бэйзлайном. Пусть даже в репозитории, пусть даже это > фактически это линк и место никак не отъедается. Во других системах > контроля версий у тебя есть дерево файлов, к каждому из которых > привязано дерево версий. Т.е существует как бы 2 измерения, в каждом из > которых ты работаешь в зависимости от потребностей. При необходимости > эти измерения "встречаются", однако элемент и их дерево версий — > разделены принципиально. В SVN же всё сводится к новым папкам. > Я уже говорил, что это классное проектное решение — всё свести к папкам, > всё становится более единообразно... однако есть случаи когда это > мешает. Пример уже приводили — в "чистом" SVN, без надстроек и скриптов, > по взятому файлу из транка нельзя сказать — в какие метки он вошел, > откуда были сделаны мержи. > Вот пример. Сколько приседаний займет в SVN подобная картина (речь для > простоты об одном файле из множества имеющися):
Кстати, на самом деле практически точно также, как в cvs.
> — выпущен бэйзлайн, он прошел тесты и считается стабильным,
svn co https://svn.company.com/project/trunk
<test, build, release baseline>
> — есть проблема Х, для решения от бэйзлайна отрастили девелоперский > бранч, частично решили на своем бранче,
svn cp https://svn.company.com/project/trunk https://svn.company.com/project/dev/X
> — фикс Y перемерживают на новый бэйзлайн, дорабатывают "косметику", > интегрируют в следующиую версию бэйзлайна.
svn merge -r 133:HEAD https://svn.company.com/project/dev/X
<test if works>
svn ci
Всё. Единственное плохо — приходится номера ревизий при merge самому
отыскивать (tsvn это позволяет делать удобнее). Есть питоновый скрипт,
svnmerge.py, который это полностью автоматизирует. А в версии 1.5 это
будет родным.
> Ответьте, апологеты SVN — вы не за%%%тесь проследить подобную картину > только по дереву версий? Без tsvn, а просто силами ядра системы? В CVS, > не говоря уже о ClearCase и P4 достаточно взять один элемент и сделать > описание файла или версии — там всё будет как на ладони, все > отращивания/мержи. Для того, чтобы сравнить изменения, отслеждить пути
В cvs мержи не показываются, о cc, p4 не знаю.
> изменений файла — не надо будет скакать между виртуальными директориями > АКА ветками, все операции делаются с одним файлом, лежащим во всё то же > дирке. > Уверен, вы найдете способы решить описанную задачу, однако сколько > усилий вы потратите?
В смысле показать картину того факта, что X было замержено в trunk? В
общем можно, как минимум по логам.
А, кстати, для чего может понадобиться такой рисунок?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[10]: Стоит ли переходить с CVS на SVN и почему?
Aquary wrote:
> .>Revision Graph в tsvn? Работает безумно долго... > Заметь — это не нативное решение, а надстройка... Ядро системы не > позволяет этого делать простыми движениями
Что значит не нативное?
Что скачивать приходится с разных сайтов?
> .>но, вообще говоря, за год использования мне никогда не потребовалось это, > А вот у меня такое — каждый день Проект крупный, отслеживание веток, > меток, мержей — каждодневная рутина.
В смысле ты каждый день рассматриваешь картинки мерджей? Что значит
отслеживание?
> .>в отличие, скажем, от переименования (которое нафиг порушит в cvs все > связи от файла к меткам). > Вот это уже вопрос к зрелости проекта и вообще проектированию... что это > за проект, где файлы часто переименовываются?
А что? Имя файла — священное и неприкосновенное животное??
Хотя да вообще-то... вспоминаю... было дело в эпоху cvs — это было
страшно менять и помню долго жили опечатки в названиях подобные
Dictonary.xml, GaleryDialog.java или InitialCod.cpp.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[11]: Стоит ли переходить с CVS на SVN и почему?
Здравствуйте, ., Вы писали:
.>Что скачивать приходится с разных сайтов?
Нет что сама система изначально почему-то этого не предусматривает
>> А вот у меня такое — каждый день Проект крупный, отслеживание веток, >> меток, мержей — каждодневная рутина. .>В смысле ты каждый день рассматриваешь картинки мерджей? Что значит .>отслеживание?
Картинки не расссматриваю Отслеживание заключается в следующем:
— разработка ведется для нескольких линеек продуктов с общим функционалом
— каждый день десятки девелоперов подают свои изменения на интеграцию
— одно изменение может идти в разные линейки
— интеграция делается для отдельной компоненты, но отстройка ведется в рамках большого продукта с кучей компонент, зависимостей между ними и т.п.
Нужно для каждого фикса
— определять базу для бранчей/версий сделанных изменений
— интегрировать изменения в нужные линейки (мержить изменения на релизные бранчи элементов на основе общей базы, в данном случае 3-хпозиционным мержем)
— некоторые изменения нужно перемерживать между линейками (автоматически, без помощи девелоперов, выбирая только нужную дельту)
"Картинки мержей" выглядят очень сложно в графике (каждый элемент изменятся десятки раз в рамках линейки продукта, линеек — с десяток), более эффективно делать всё с командной строки + некоторые скрипты. Т.е. требуется максимум возможности для просмотра истории внесения и миграции изменений — и это при минимуме затраченных усилий, т.к. просмотреть нужно много.
В SVN подобная ситуация будет совсем не проще, чем в CVS... Одинаковая обширная задница и плюсы SVN над CVS тут никак не помогают, через CVS подобное можно было бы сделать чуть проще. ИМХО . Хотя, до заюзанного в моем случае ClearCase всё равно далеко
Кстати, в другом посте проскочило, что CVS не показывает мержи... показывает, ещё как показывает...
.>А что? Имя файла — священное и неприкосновенное животное??
Нет, зачем же надо менять имя — значит надо... Повторюсь — обычная фича... Но отнюдь не супернаворот, который привозносят по всех обзорах
Здравствуйте, Aquary, Вы писали:
.>>А что? Имя файла — священное и неприкосновенное животное?? A>Нет, зачем же надо менять имя — значит надо... Повторюсь — обычная фича... Но отнюдь не супернаворот, который привозносят по всех обзорах
Ну зачем вот это, "супернаворот", "превозносят"? Вопрос был — "какие преимущества?" Вот возможность переименовать — это преимущество, большое, маленькое, не важно. Для кого-то одна фича "супернаворот", для кого-то другая.
Re[12]: Стоит ли переходить с CVS на SVN и почему?
Aquary wrote:
> .>Что скачивать приходится с разных сайтов? > Нет что сама система изначально почему-то этого не предусматривает
Что значит сама система? Что именно не предусматривает?
Единственное что svn command line не позволяет — нарисовать картинку
revision graph, которая как ты правильно заметил — бесполезная, ибо
слишком сложная.
> Нужно для каждого фикса > — определять базу для бранчей/версий сделанных изменений
copy-запись в истории.
> — интегрировать изменения в нужные линейки (мержить изменения на > релизные бранчи элементов на основе общей базы, в данном случае > 3-хпозиционным мержем)
svn merge (или tsvn если мышой нравится щёлкать).
> — некоторые изменения нужно перемерживать между линейками > (автоматически, без помощи девелоперов, выбирая только нужную дельту)
svn merge (или tsvn если мышой нравится щёлкать). Пожалуйста,
автоматизируй, например с помощью svn-py. Правда при мерджах возможны
конфликты... совсем без девелоперов не получится, понятное дело.
> "Картинки мержей" выглядят очень сложно в графике (каждый элемент > изменятся десятки раз в рамках линейки продукта, линеек — с десяток), > более эффективно делать всё с командной строки + некоторые скрипты. Т.е. > требуется максимум возможности для просмотра истории внесения и миграции > изменений — и это при минимуме затраченных усилий, т.к. просмотреть > нужно много.
Что именно нужно просмотреть? В svn, если использовать svnmerge.py, то
для типичного мерджа достаточно обычно набрать "svnmerge merge", "svn ci
-F svnmerge-commit-message.txt" и ничего смотреть не надо.
> В SVN подобная ситуация будет совсем не проще, чем в CVS... Одинаковая > обширная задница и плюсы SVN над CVS тут никак не помогают, через CVS > подобное можно было бы сделать чуть проще. ИМХО . Хотя, до заюзанного в > моем случае ClearCase всё равно далеко
О cc ничего не знаю...
> Кстати, в другом посте проскочило, что CVS не показывает мержи... > показывает, ещё как показывает...
Кхм... Не помню такого. А как показывает?
> .>А что? Имя файла — священное и неприкосновенное животное?? > Нет, зачем же надо менять имя — значит надо... Повторюсь — обычная > фича... Но отнюдь не супернаворот, который привозносят по всех обзорах
Кто превозносит? Хотя, да, для cvs это было серьёзной проблемой, так что
стоит упоминания.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[12]: Стоит ли переходить с CVS на SVN и почему?
К>>Очень странное замечание. К>>1. Только убожеством системы контроля версий можно оправдать исскуственное ограничение на (не)переименовывание файлов A>Я и не говорил, что раз в CVS этого нет, то и не надо просто это так сильно превозносят поклонники SVN, как будто это самая главая фича любой системы контроля версий
Дело в том что с точки зрения простого девелопера, у которого работа с системой контроля версий занимает 20 минут в день, у SVN не так уж много преимуществ перед CVS. Интерфейс и идеология использования похожи, некоторые просто не заметят переезда. Так вот, преимущества такие:
— возможность переименовывать файлы без потери истории
— возможность (nix-овые девелоперы поймут) добавить/убрать файлу атрибут "Executable" в любой момент, а не только в момент добавления в VCS.
— что-то ещё?
Всё остальное — атомарность коммита, zero-cost бранчевание и т.п. — это в большинстве случаев не для обычного девелопера, это чаще для CM-а или человека который исполняет его обязанности. Потому-то по форумам и создаётся впечатление что возможность переименовывать файлы — это главное преимущество.
К>>2. Возможно это делается и не часто, но иногда бывает нужно в любом проекте. A>Вот и отлично, что есть. Но и безпереименования жить можно неплохо
А ты попробуй жить с переименованием, а потом от него откажись. Сразу почувствуешь нужная это фича или нет.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[13]: Стоит ли переходить с CVS на SVN и почему?
Здравствуйте, Left2, Вы писали:
L>Дело в том что с точки зрения простого девелопера, у которого работа с системой контроля версий занимает 20 минут в день, у SVN не так уж много преимуществ перед CVS. Интерфейс и идеология использования похожи, некоторые просто не заметят переезда. Так вот, преимущества такие: L>- возможность переименовывать файлы без потери истории L>- возможность (nix-овые девелоперы поймут) добавить/убрать файлу атрибут "Executable" в любой момент, а не только в момент добавления в VCS. L>- что-то ещё?
Ещё возможность посмотреть кто что менял за последнее время — можно просмотреть лог. Есть ли в CVS незатратная возможность узнать, кто какие файлы закоммитил за посленюю неделю, за вчера?
L>Всё остальное — атомарность коммита, zero-cost бранчевание и т.п. — это в большинстве случаев не для обычного девелопера, это чаще для CM-а или человека который исполняет его обязанности. Потому-то по форумам и создаётся впечатление что возможность переименовывать файлы — это главное преимущество.
Бранчевание для разработчика как раз очень удобно по-моему. Решил что-то серьёзное сделать — отбранчил, сделал, смерджил.
Это больше похоже общие вопросы программирования -> управление проектами
Есть создание линка. Но это всё детали. Какая юзеру разница, как оно внутри реализовано, главное ведь, что функциональность присутствует.
. Я в этой ветке пытаюсь убедить всех что SVN лучше CVS, а не то что SVN лучше всех 
