> man operating_systems
Проект KDE станет самым большим проектом перешедшим с CVS на Subversion
Проект KDE готовится к миграции на систему управления версиями Subversion, для перевода потребуется около 12 часов. Планируется 31 марта в 8 утра перевести cvs.kde.org в режим только для чтения, а в 8 вечера - открыть доступ к svn.kde.org, подготовив таким образом почву для первоапрельского анонса.

Полное обсуждения миграции доступно здесь (English).

  • Достоинства Subversion: поддержка почти всех функций CVS, устранение главных недостатков CVS (нет прямых средств для переименование файлов и директорий, неэффективное хранение бинарных файлов, не атомарные commit'ы);
  • Недостатки Subversion: относительно большая ресурсоемкость, проблемы с объединением ветвей, сервер на базе HTTP.


По материалам OpenNET.ru
Roman I Khimov  в  Понедельник, 28 Март 2005, 10:12  |   Комментарии: 40  |  для печати

Комментарии
Dron |28.03.2005 11:14
Комментарии: 558


CVS конечно морально устарел...
но лично мне SVN тож не нравится... хотя может я чего-то не понимаю... два раза буку почитал... как-то темно...

vilmor |28.03.2005 12:30
Комментарии: 27

Зарегистрирован: 29.10.2004 17:09

Не, SVN рулит
Там всё проще и удобнее, чем в CVS.
Лично я уже довольно давно на него перешёл.

Dron |28.03.2005 14:34
Комментарии: 558


Тяжелый он... че там столько напихали?
Я вообще тяжелых программ не люблю.

Да и достаточно неинтуитично... какие-то Trunk...
И еще я не понял... вот типа Trunk, в нем только располагаются подкаталоги проектов? а если я хочу бранчи держать рядом с основной ветвью? короче имхо намудрили...

Помоему контроль версий должен базироваться на проектах (а не на файлах)..
А таг - помоему это просто метка... (а не копия как думают в svn)

Хотя может я просто чего-то не понимаю.

vilmor |28.03.2005 15:55
Комментарии: 27

Зарегистрирован: 29.10.2004 17:09

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

По поводу веток.
Сейчас считается общепринятым на каждый проект создавать отдельный корневой каталог, в котором размещать каталоги trunk, branches и tags. Trunk содержаит стволовую ветку проекта. Branches содержит отдельные каталоги для каждой из веток. Tags содержит отдельные каталоги для каждого из тегов.

Да и достаточно неинтуитично... какие-то Trunk...
И еще я не понял... вот типа Trunk, в нем только располагаются подкаталоги проектов? а если я хочу бранчи держать рядом с основной ветвью? короче имхо намудрили...

В svn ветка или тег - это логичесвкая копия проекта. на самом деле, в ней нет никаких данных, поскольку svn хранит только изменения. Таким образом, разработчики svn избавились от лишнего понятя "метка", заменив его на использование подкаталогов branches.

Помоему контроль версий должен базироваться на проектах (а не на файлах)..
А таг - помоему это просто метка... (а не копия как думают в svn)

Не совсем понимаю, что подразумевается под контролем версий на основе файлов, не проектов. Можно, конечно, организовать структуру репозитория без всяких проектов, оставив в нём только общие бля всех файлов репозитория trunk, branches и tags. Но это попросту неудобно.

vilmor |28.03.2005 16:04
Комментарии: 27

Зарегистрирован: 29.10.2004 17:09

немного накосячил. плохо, что нет возможности подредактировать.

captain cobalt |28.03.2005 16:24
Комментарии: 83

Зарегистрирован: 04.07.2004 21:44

Dron написал(а) ...
Тяжелый он... че там столько напихали?
Я вообще тяжелых программ не люблю.

Тяжёлые программы требуют тяжёлых систем контроля версий. Чем тяжелее программа, тем для неё тяжелее требуется система контроля версий. Не удивлюсь, если через некоторое время появится нечто потяжелее Subversion, а потом ещё тяжелее, и т. п.

Существует альтернативный путь, так называемый Unix way, суть которого в том, что программная система строится из множества независимых, но способных к взаимодействию программных единиц. Каждой такой маленькой программой вполне может заниматься один разработчик. Система контроля версий при этом обычно оказывается вообще не нужна.

Камнем преткновения, иногда перерастающим в серъёзную проблему, такого подхода является то, что для успешного взаимодействия необходимо строго зафиксировать программные интерфейсы. На первый взгляд кажется несложно разработать сотню-другую интерфейсов на все случаи жизни, и пользоваться ими всю оставшуюся жизнь. Увы, хорошего решения до сих пор не предложено. На мой взгляд, всем новоявленым "писателям ос" следует уделить самое пристальное внимание именно этому вопросу.

vilmor |28.03.2005 17:30
Комментарии: 27

Зарегистрирован: 29.10.2004 17:09

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

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

Я бы не сказал, что svn трудно настроить. Можно просто установить его как WinNT-сервис, работающий по протоколу svn://. Можно даже этого не делать, и использовать протокол file://.

Между прочим, для SamplOS я использую svn-репозиторий, доступный по протоколу https на моём tirion.ivanco.net. Правда, пока он открыт только для участников проекта

Dron |30.03.2005 10:16
Комментарии: 558


Ну не знаю, мне не нравится.
(мне вообще ничего не нравится - нигиллист я.

Ну меня не сильно удивляет архив ядра на 36 мег... (учитывая сколько там драйверов) но меня удивляет архив subversion в 6 мег по сравнению с архивом cvs в 3 мега...
Именно это я имею в виду, когда говорю тяжелый.

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

И вообще в линуксе очень большое дублирование кода... (я думаю и везде в юниксе так.)

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

Кстати вот про UnixWay - что cvs что svn - это не оно...
вот arch - оно... а эти - неправильно...

Dron |30.03.2005 10:20
Комментарии: 558


PS: Я нисколько не умаляю пользы системы контроля версий... такие системы нужны и важны! (не поймите меня неправильно)
Но должна быть красота!

vilmor |30.03.2005 12:39
Комментарии: 27

Зарегистрирован: 29.10.2004 17:09

Ну меня не сильно удивляет архив ядра на 36 мег... (учитывая сколько там драйверов) но меня удивляет архив subversion в 6 мег по сравнению с архивом cvs в 3 мега...
Именно это я имею в виду, когда говорю тяжелый.

Похоже на то, что ты смотрел размер забзипованых сырцов. А там случайно нет каталогов ".svn"? Похоже, что есть, и в них хранится полная копия всех остальных файлов. Размер распакованных файлов - 54М, а без всех ".svn" - только 19М. Архив без ".svn" - только 3.8М, что не так и много

Почему в ".svn" хранится так много избыточных данных? В мануале про это написано. Просто это ещё одна рулезная фича, которая заключятся в том, что клиент может сравнить свою рабочую копию с изначально извлечённой ревизией, не соединяясь с сервером. Кроме того, при коммитах, трафик между клиентом и сервером меньше, поскольку клиент сам знает, какие измения отсылать на сервер. В CVS изменения рабочей копии сравнивались на сервере, а в SVN - на стороне клиента. Всё это очень хорошо для диалапщиков, которые теперь могут меньше времени тратить на коммиты, да и подключаться к нету им не надо, если они просто хотят узнать, какие изменеия были сделаны в локальной копии, относительно текущей ревизии.

vilmor |30.03.2005 12:45
Комментарии: 27

Зарегистрирован: 29.10.2004 17:09

PS: imho, Subversion получился очень простой и красивой системой по своей архитектуре. Но с реализацией некоторых идей пока есть довольно серьёзные проблемы.

PPS: ну, мне тоже многое не нравится Но только когда я говорю об этом, меня часто просят оставить это при себе =)

Dron |30.03.2005 14:40
Комментарии: 558


Про каталог .svn я в курсе... только нафига его тащить в архив??? в архив надо тащить экспортированную чистую копию...

Если они половину архива потратили на это - то ламеры!

В принципе систем контроля версий много... (я правда для себя так особо ничего и не выбрал... капризный наверное очень

Но мне странно позиционирование svn как замены cvs... svn просто еще один из... со своими плючами и минусами...

Кстати чем KDE-шники мотивируют необходимость перехода?
Смысл? насчет отсутствия возможности переименования - это тоже не просто так... (и cvs не дураки делали)...

Когда программу разрабатывает один человек, ему и парится особо не за чем... а вот когда 100 человек, здорово будет, если один из них возьмет да переименует каталог или файл.

Меня вот убивает SourceSafe на работе... там (при наличии прав, но всеравно) есть возможность все удалить на совсем!

Вот в CVS такое нельзя и правильно!
Поэтому к свободе переименований я тоже отношусь прохладно. И какие еще положительные стороны остались у SVN?

vilmor |30.03.2005 15:58
Комментарии: 27

Зарегистрирован: 29.10.2004 17:09

Про каталог .svn я в курсе... только нафига его тащить в архив??? в архив надо тащить экспортированную чистую копию...

Полностью согласен. Ламеры

В принципе систем контроля версий много... (я правда для себя так особо ничего и не выбрал... капризный наверное очень

Да, много. И я, в силу своей ужасающей лени, знаю только CVS, VSS и SVN. Но то, что я знаю об SVN, мне нравится, потому что там _очень_ много полезных для меня фич. Теперь, когда по работе возникают затруднения с корпоративным CVS-репозиторием, постоянно приходит в голову, что в SVN такая проблема решается куда проще... Ну, взять хотя бы те же svn:externals.

Но мне странно позиционирование svn как замены cvs... svn просто еще один из... со своими плючами и минусами...

Он так позиционируется потому, что можно мигрировать сервер с CVS на SVN, и при этом пользватели могут продолжать пользоваться им через команду CVS. Есть там у них какие-то обёрточные скрипты. чтобы SVN-сервер прикидывался CVS-сервером...
По той же причине, с SVN можно продолжать пользовать ViewCVS для просмотра SVN из web.
И всё-таки, в SVN куда больше плюсов, чем минусов

CVS не дураки делали, конечно. Но SVN - это результат эволюции, и в нём были учтены прежние ошибки.

А VSS - однозначно, давить!

Вот в CVS такое нельзя и правильно!

Как показывает практика, можно. Админ берёт, и удаляет часть файлов репозитория =)
Знаю, это криво, но народ так делает.

Поэтому к свободе переименований я тоже отношусь прохладно. И какие еще положительные стороны остались у SVN?

Так ведь в SVN при этом история не убивается.
А фичи... их много, надо по мануалу смотреть.

Dron |30.03.2005 18:12
Комментарии: 558


Кстат, вот такой вопрос на засыпку... SVN Book еще не перевели на русский язык?

vilmor |30.03.2005 20:34
Комментарии: 27

Зарегистрирован: 29.10.2004 17:09

вряд ли...
не знаю, я даже и не искал переводной вариант



Комментарии доступны только авторизованным пользователям, авторизуйтесь или зарегистрируйтесь на сайте здесь

© OSRC.info, 2004-2010.
Авторские права на любые материалы, авторы которых явно указаны, принадлежат их авторам. По вопросам публикации таких материалов обращайтесь к авторам.
Авторские права на любые другие материалы принадлежат OSRC.info.
Сайт является помещением библиотеки. Копирование, сохранение на жестком диске или иной способ сохранения произведений осуществляются пользователями на свой риск.
При использовании материалов сайта ссылка на OSRC.info обязательна.