Обсуждение:Subversion/Архив август 2005 - август 2010

subversion - подверсия

возможно использование данного термина в системе нумерования версий: версия.подверсия.релиз.сборка

Скорее всего, разработчики специально (с маркетинговыми целями) дали двусмысленное имя, чтобы подчеркнуть преимущества продукта и обеспечить более скорый переход от CVS. По данным Яндекс.Лингво английское слово "subversion" в основном значении переводится как "низвержение, низложение, ниспровержение, свержение". И это есть факт. Всё остальное -- гипотетические предположения, которые надо проверить и подтвердить источниками.--GBuilder 13:33, 11 ноября 2006 (UTC)

Я, вообще-то, недостаточно хорошо знаю английский, но у меня сложилось впечатление, что основное значение — единственное. Я не смог нигде найти второго значения. То, что это игра слов — очевидно. --SergV 19:57, 11 ноября 2006 (UTC). На сайте subversion написано, что название придумал Джим Бланди, живущий в Орегоне. Вряд ли он мог просто придумать новое слово и не заметить такого интересного совпадения. --SergV 20:09, 11 ноября 2006 (UTC)

"Я, вообще-то, недостаточно хорошо знаю английский, но у меня сложилось впечатление..." - МОГУЧИЙ аргумент!!!

К несчастью, именно по такому принципу вся русская Википедия похоже составляется. И редактор этой статьи из таких же, как видно. Так вот я английский знаю очень хорошо, работаю в канадской компании в Канаде и более того, опросил несколько так называемых носителей языка, которые как раз с этой системой работают. Никакой ассоциации со словом subversion в значении свержение у них не возникает. Пилите... пардон, редактируйте дальше!

Оскорбления тоже не самый лучший аргумент. Русская Википедия строится (или пытается) по принципу проверяемости. Вы можете чем-нибудь подтвердить, что Джим Блэнди из тех носителей языка, которые не знают значения этого слова и думают, что это просто синоним subrevision? --SergV 13:57, 15 ноября 2006 (UTC)

Посмотрите Слои

Я перевел секцию Слои (оригинал см. в английской статье). Но как-то слабовато получилось в итоге, нет той ясности, которую хотелось бы иметь. То ли в английской статье текст слабоват, то ли перевел плохо... Посмотрите, кто разбирается в вопросе (сам с внутренним устройством дела не имел). --Кae 19:26, 12 июня 2008 (UTC)

Сделать избранной или хорошей

Предлагаю довести эту архиважную статью до уровня избранной или хотя бы хорошей (ИМХО на хорошую уже можно выставлять хоть сейчас). Со своей стороны могу еще многое в статье написать, но затрудняюсь с выбором темы — вроде бы все по немногу уже есть. Пожалуйста, посмотрите и скажите, какие темы еще следует раскрыть. Учитывайте, что статья не должна быть полным справочным руководством, поэтому описывать команды и т.п. не стоит. (Пустую секцию «Типовые приемы использования ветвей» скоро допишу) --Кae 12:20, 5 октября 2008 (UTC)

централизованная

По-моему, в основное определение это можно не вставлять. 90 % таких систем — централизованные. Это и дальше раскрыто. В статьях про CVS и Perforce в первом определении этого нет и всё понятно. --korvin2050 11:25, 26 января 2009 (UTC)

Некоторое время назад я задавал себе вопросы типа: «что лучше: Subversion или Git (Mercurial, Bazaar и т. д.)?» «А может перевести хранилища с Subversion на одну из этих систем?». После некоторых поисков стало понятно, что централизованные и распределенные системы довольно сильно отличаются по своей идеологии. Вопрос разрешился так: Subversion — централизованная, а Git/Mercurial/Bazaar — распределенные и не являются прямым конкурентом централизованным. Они просто другие и для несколько других условий. Поэтому нужно обязательно акцентировать внимание на типе системы. См. также статью: [1].

Статьи CVS и Perforce не имеют упоминания о централизованности, и это плохо. Вообще эти статьи очень слабые, не нужно на них равняться.

«90 % таких систем — централизованные» — вы делаете типичную ошибку начинающих википедистов :-). Утверждения с цифрами (здесь, в википедии) можно делать только если они подкреплены результатами авторитетного исследования. Если такого исследования не было, то утверждение о 90 % — всего лишь ваше мнение. Я вот хотел бы написать, что Subversion уже опередил по распространенности CVS (и это наверняка так), но не могу, так как нет авторитетного источника, который провел бы такое исследование. То же самое о распространенности терминов типа «коммитить». См. также ВП:АИ

--Кae 13:07, 26 января 2009 (UTC)

CVS и Perforce не имеют упоминания о централизованности в самом начале, дальше оно есть.

Про 90% теоретически с вами согласен, АИ не привёл. Но фактически в Майкрософте, Гугле, Сане, и других крупных компания, про которые мне известно, используются централизованные системы. --korvin2050 13:31, 26 января 2009 (UTC)

Рецензия с 25 января по 9 февраля 2009 года

Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

Прошу отрецензировать статью. Интересует как мнение людей, связанных с программированием (которые по идее должны использовать системы управления версиями), так и неспециалистов в данной области, которые могут оценить читабельность свежим взглядом. Замечу, что в других языковых разделах статья в разы меньше по объему материала. В перспективе предполагается номинирование в избранные или хорошие. --Кae 14:54, 25 января 2009 (UTC)

Отличная статья. Можно сразу на хорошие подавать.

Что-то поправил, и есть несколько замечаний:

• Мне не нравится термин "публикация изменений". На практике обычно используется английская калька "закоммитить", "зачекинить", "залить". В статье CVS используется тоже плохой вариант "регистрация изменений".
• Ревизия тоже не нравится, на практике используется "версия" или "ревижен".
• "Библиотеки для языков PHP, Python, Perl, Java." - лучше перефразировать, непонятно о чём речь.
• "Поэтому при изменении даже одного файла создаётся новая ревизия всех имеющихся в хранилище файлов и директорий." - Перефразировать, иначе создаётся ощущение, что что-то делается с каждым файлом и каталогом.
• "HEAD (головная ревизия)" - на практике используется "текущий", "последний", "хед".
• "Как правило, создание рабочей копии является первым и необходимым этапом для публикации локальных изменений,

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

• Добавить пару слов о локальных/удалённых версиях многих команд.
• svn switch можно использовать не только для ветки, а для любого файла или каталога в рабочей версии. И эта версия войдёт в метку или копию.
• В сравнении эффективности можно добавить, что CVS хранит версии в прямом порядке, а SVN - в обратном, что ускоряет работу с хедом. Или это про Perforce, надо проверить.

--korvin2050 16:58, 25 января 2009 (UTC)

Кое-то сразу поправлю или приму к сведению, кое-что прокомментирую:

• По поводу "публикация изменений": в книге по Subversion используются термины фиксация и публикация, причем фиксация чаще. Если нет возражений, то заменю все на фиксации. Любые англоязычные заимствования не годятся по двум причинам: во-первых, слов типа "закоммитить" в русском языке нет (т.е. это орисс), во-вторых, нельзя быть уверенным, что этот термин глобален (возможно, он имеет хождение только в вашей команде?). Книга является наиболее АИ.
• Ревизия: должно быть именно ревизией (в книге так, других вариантов нет).
• "HEAD (головная ревизия)": тоже вроде бы нет хороших вариантов для замены.
• "обычный рабочий цикл" и "локальные/удалённые версии команд": да, надо. Думаю, как перестроить структуру чтобы органично вставить это.
• "svn switch можно использовать не только..." - да, но не очень понял, к чему это (в каких ситуациях следует использовать). Смешать в метке файлы из разных ветвей/директорий? --Кae 21:17, 25 января 2009 (UTC)

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

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

Можно смешать, например, если в релизе не нужны последние изменения или их часть. Конечно, можно создать метку, и уже в ней поправить, но это методически неверно. Теоретически в рабочей копии месиво из разных версий (сомневаюсь в большой пользе), а потом его забранчить.

--korvin2050 23:32, 25 января 2009 (UTC)

Поставил себе русский TortoiseSVN. Посмотрите, я положил картинку с русским интерфейсом. В его локализации используется "фиксировать" и "ведущая (HEAD)". --korvin2050 23:45, 25 января 2009 (UTC)

• Прекрасная статья. Также возражаю против жаргонизмов типа "закоммитить"//Berserkerus 10:53, 9 февраля 2009 (UTC)

Google начала поддержку mercurial

Посему рекомендую поправить "В системах Google Code и BountySource используется исключительно Subversion."

92.126.52.105 07:58, 5 мая 2009 (UTC) zalex

Subversion и CVS

Обеспокоил такой текст

Параметр	Subversion	CVS
Модификации имён файлов	Поддерживает копирование, перемещение и переименование файлов и директорий без потери истории изменений.	При копировании, перемещении и переименовании файлов файл с новым именем не имеет никакой истории, то есть связь со старым именем и его историей версий полностью теряется. То же самое для файлов внутри директории при модификации её имени.

В 1.6.9 точно при перемещении директорий(точнее как такового перемещения там не существует, GUI-клиенты эмулируют это парой операций Копировать+Удалить) история теряется безвозвратно. Т.е. точно такая же ситуация как и с CVS.

Или может быть я чего-то пропустил?(Не помешало бы ссылку на это "чего-то")

Действительно, можно сказать, что перемещение эмулируется парой операций Копировать+Удалить. Все дело в том, что понимать под словом копирование.

• Неправильный способ (который приводит к «разрыву» истории). Объект со старым именем удаляется, объект с новым именем копируется средствами файловой системы со старого. Да, это выглядит как копирование+удаление, но на самом деле (в терминах Subversion) это добавление_нового+удаление, т.к. Subversion ничего не знает о том, что новый объект должен продолжить свою историю от удаленного. Если посмотреть историю (svn log) нового объекта, то она начинается с точки добавления.
• Правильный способ (с сохранением истории) выполняется командой svn move. Объект со старым именем удаляется, объект с новым именем копируется средствами Subversion со старого. В терминах Subversion это копирование_с_историей+удаление, при этом новый объект наследует свою историю от удаленного. Если посмотреть историю (svn log) нового объекта, то увидим, что перемещенный объект имеет всю историю объекта со старым именем.

Вот примеры лога. Здесь ревизия 13 - неправильное перемещение, 17 - правильное. Обратите внимание, что при правильном перемещении новый файл знает, откуда он был скопирован (хотя операция называется "A", что немного вводит в заблуждение).

------------------------------------------------------------------------
r13 | User.Name | 2010-04-13 21:39:07 +0400 (Вт, 13 апр 2010) | 1 line
Changed paths:
   D /trunk/file.txt
   A /trunk/file_new.txt

Incorrect move
------------------------------------------------------------------------
...
------------------------------------------------------------------------
r17 | User.Name | 2010-04-13 21:43:18 +0400 (Вт, 13 апр 2010) | 1 line
Changed paths:
   A /trunk/Dir/file_new_name.txt (from /trunk/file.txt:16)
   D /trunk/file.txt

Correct move
------------------------------------------------------------------------

Вот для полноты картины лог переименованного объекта (/trunk/Dir/file_new_name.txt). Как видим, история в наличии :-).

------------------------------------------------------------------------
r15 | User.Name | 2010-04-13 21:41:07 +0400 (Вт, 13 апр 2010) | 1 line
Changed paths:
   A /trunk/file.txt

File is added
------------------------------------------------------------------------
r16 | User.Name | 2010-04-13 21:41:53 +0400 (Вт, 13 апр 2010) | 1 line
Changed paths:
   M /trunk/file.txt

File is modified
------------------------------------------------------------------------
r17 | User.Name | 2010-04-13 21:43:18 +0400 (Вт, 13 апр 2010) | 1 line
Changed paths:
   A /trunk/Dir/file_new_name.txt (from /trunk/file.txt:16)
   D /trunk/file.txt

Correct move
------------------------------------------------------------------------

Что касается клиентов, то они должны иметь функциональность команды svn move. Например, в TortoiseSVN для перемещения надо перетащить объект правой кнопкой мыши в новое место. В SmartSVN (именно им я пользуюсь) можно перетащить левой кнопкой или выбрать "move" в контекстном меню объекта. --Кae 18:01, 13 апреля 2010 (UTC)

Забыл сказать про CVS. Там команды move нет, т.е. перемещения выполняются всегда первым («неправильным») способом, и сохранить историю нет никакой возможности.--Кae 18:36, 13 апреля 2010 (UTC)

Комманда svn help move в часности выдает

 Note:  this subcommand is equivalent to a 'copy' and 'delete'.

Делаю манипуляцию с каталогом test1

 svn move test1 test2
 svn ci -m "svn move 1->2"

в результате чего получаю конфликт при удалении test1 и естественно откат всего commit-а так что атомарность svn move отсутствует Уж не знаю как GUI клиенты вызывают, но тот факт что я остался без двухмесячной истории неоспорим.

Отвечу кратко:

• svn move действительно является эквивалентом 'copy' и 'delete'. Никто с этим не спорит.
• конфликт при удалении test1 никак с историей не связан
• откат всего commit-а как раз и означает атомарность
• Есть возможность восстановить потерянную историю, но желательно это делать как можно скорее после фиксации, нарушающей историю.

Я могу проконсультировать по любым вопросам, связанным с Subversion. Но задавайте их лучше на моей странице обсуждения, т.к. здесь надо обсуждать статью, а не сам Subversion. --Кae 18:57, 14 апреля 2010 (UTC)

Предложения по улучшению

• В возможностях написано "# Реализовано большинство возможностей CVS.", а в статье про CVS никакие возможности не описаны.

  Попробую что-нибудь сделать. Хотя CVS фактически мертва, развивать статью о ней не очень хочется.--Кae 08:01, 20 июня 2010 (UTC)

  Может, тогда и нет смысла так пристально останавливаться на сравнении именно с CVS? Kmorozov 09:43, 20 июня 2010 (UTC)

• Провести сравнение с другими системами версионности, чтобы было понятно место Subversion в более широком контексте Kmorozov 06:05, 20 июня 2010 (UTC)

  Это тема отдельной статьи, надо перевести английскую en:Comparison of revision control software.--Кae 08:01, 20 июня 2010 (UTC)

Что касается ярлыка «устаревший»

Уважаемые участники, прекратите преждевременные похороны CVS, и навешивание на нее ярлыка «устаревшая». Это не соответствует действительности, чтобы не писали об этом отдельные личности в пингвинячьих журналах. Система станет устаревшей когда ее перестанут использовать все, до тех пор извольте придерживаться NPOV. И вообще, статья в данный момент вместо описания Subversion лишь создает контроверсию CVS, что попросту глупо. Grain 13:16, 28 июня 2010 (UTC)

Не спору ради: вроде как развитие CVS прекращено, только поддержка. Системы обычно становятся устаревшими задолго до того, как их прекращают использовать. Нет ли часом где статистики использования? Я ничего достоверного не нашел — Hudolejev 08:06, 29 июня 2010 (UTC)

Насчет якобы прекращения работ над GNU CVS, мне ничего неизвестно, но OpenBSD-team все еще ведет работы над OpenCVS — BSD-реимплементацией в которой, кроме всего прочего планируется доработать оригинальный алгоритм и исправить его глубинные огрехи, кроме того есть же еще и CVSNT. Статистику использования надо собирать (без нее нельзя утверждать ничего вообще). CVS же используют, как минимум OpenBSD и NetBSD, а FreeBSD перекрещенный неким редактором на SVN, на самом деле использует и CVS и SVN … А вообще, дурни кричащие на каждом углу о новом супер-пупер проекте будь то правильный Jabber или богомерзкий skype и обсирающие все остальное ни одному проекту на пользу не идут. Grain 11:29, 29 июня 2010 (UTC)

Вот тут все глухо, последний релиз с новыми фичами в был 2005-м году, далее только фиксы. OpenCVS тоже еле шевелится, одни новости чего стоят. Устаревшей, как я понял, CVS обозвали отнюдь не упомянутые участники, а RedHat Magazine еще в 2005-м году ([2]). Что, по-вашему, должно еще случиться с продуктом, чтобы безболезненно можно было бы назвать его устаревшим? Использование тем-то и тем-то тут не показатель, некоторые наверняка и Windows NT 4.0 пользуют, и JRE 1.2, и мало ли какие еще экспонаты — Hudolejev 12:40, 29 июня 2010 (UTC)

Насчет статистики: буквально на днях я добавил в начало статьи две ссылки на статистику использования Linux-пакетов (см. «По данным статистики использования пакетов …» и далее). --Кae 13:19, 29 июня 2010 (UTC)

1. Пропаганда полярна и неавторитетна по определению (а уничижающие высказывания о CVS в статьях об SVN, таких как приведенная вами, да и отчасти та, которую мы обсуждаем, это пропаганда).
2. Инструменты успешно используемые хоть сколько нибудь широким кругом пользователей (а не энтузиастами винтажа) устаревшими без существенных оговорок названы быть не могут. точка.

Да, уже посмотрел на гнушный ftp, они особо не чешутся. О реальном прогрессе OpenCVS лучше видно в репозитории, а на сайте они мало что пишут. Прогресс, действительно, невелик, но боюсь это не сколько от того что «SVN круче», сколько от того что GNU CVS разработчиков в процессе работы более или менее устраивает. Когда они доведут процесс до логического конца, то никакой SVN нужен не будет. Лично меня, GNU CVS не устраивает только отсутствием разграничений на доступ, которые OpenCVS должен побороть. IHMO, разработка софта вообще, и инструментария в особенности, должна быть инкрементальной, а стремление постоянно все переписывать с нуля (и неизбежные толпы безмозглых фанатичных подростков) контрпродуктивно.

Вообщем, предлагаю, переписать статью о Subversion вообще без упоминания CVS в суе, тем более в определении с стиле "GNU is Not Unix" "SVN is Not CVS", как это сделано сейчас, а определение устаревшая/неустаревшая оставить для статьи о CVS. Grain 14:05, 29 июня 2010 (UTC)

(Участнику Grain, ответ на первый пост в секции): на мой взгляд, вы внесли гораздо больше сумбура и POV своими правками. Давайте разберемся во всем по-порядку.

1. В самом первом предложении вы оставили перевод термина "Subversion" в смысле "под-версия", а значение "свержение" отодвинули подальше, указав, что оно всплывает только в контексте заявлений разработчиков. Пожалуйста, приведите АИ, который бы доказывал, что именно "под-версия" является первичным значением "Subversion". Если таковых АИ не окажется, то придется вернуть как было (т.е. оба смысла равнозначны).
2. Вот это непонятно: «позиционируемой авторами, и некоторыми разработчиками …» — какими авторами и какими разработчиками?
3. «подчеркивающая гипотетически неизбежную победу …» — очень вольная трактовка. Я ничего не слышал о неизбежности победы. Откуда это (приведите АИ)?
4. «…, но имеет свои особенности и недоработки» — это вообще пустые слова. Убираю сразу как тривиальное и риторическое утверждение. Поскольку все имеет свои недостатки, эта ваша фраза будет верна при любом сравнении, например:
   • «АКМ свободен от ряда недостатков аркебузы, но имеет свои особенности и недоработки»
   • «Windows 7 свободен от ряда недостатков Windows 95, но имеет свои особенности и недоработки»
5. Устаревание — это не ярлык, а конкретный экономический термин. И в случае CVS он вполне применим вследствие появления «новых более совершенных или более популярных версий аналогичного оборудования/ПО или технологий». Как только ПО перестает развиваться, оно начинает устаревать. И статистика распространенности не является ключевым показателем. Например, в организации, где я администрирую системы управления версиями, код старых продуктов лежит в CVS (и еще долго будет лежать) ради совместимости с другими старыми системами.
6. «Система станет устаревшей когда ее перестанут использовать все» — откуда такое определение устаревания? Опровергаю контрпримером: если я поставлю себе Windows 1.0, то эта система сразу выйдет из разряда устаревших? Так что давайте использовать общепринятые определения.
7. Можете привести хотя АИ (скажем, не старше двух лет), которые бы рекомендовали устанавливать и исползовать CVS? Я привел много АИ, которые этого делать НЕ рекомендуют. --Кae 14:18, 29 июня 2010 (UTC)

Прежде всего, повторюсь, место для описания преимуществ и недостатков, а также навешивания всевозможных ярлыков на CVS и ее многострадальные реализации есть страница CVS, или страница сравнения систем контроля версий. Дублирование поклёпа этой информации в статье о Subversion несколько излишне (разве что в плане истории и явно выделеных цитат с указанием авторства). Теперь пройдем по репликам.

POVs там были до меня, я их не тронул, я лишь определил их явно.

1. «Subversion» — не приключенческий фильм и не дворцовый роман, а инструмент для управления версиями (англ. version), поэтому первичность значения названия «подверсия» никакого сомнения вызывать не должно не несите пургу. А вот пресловутая «игра слов» и «свержение» в тему наоборот никак не вписываются и требуют АИ. Самому же факту об интересном варианте перевода слова, случайно или намерено подчеркивающему контроверсию CVS, в отсутствие внятных АИ, место где-нибудь в разделе «Интересные факты», и никак не выше. Кроме того — посмотрите на логотип, в нем слово разделено цветом на две части SUB и VERSION. Если остались сомнения, давайте устроим опросец. А у слова англ. version, кстати, еще больше значений:
   • (новая) версия/интерпретация/вариант/видоизменение/модификация/переложение/перевод/текст/издание
   • акушерский поворот плода (в матке)
   • патологический наклон (матки)
   • содружественный поворот (глазных яблок)
   • и глагол англ. to version — создавать новую версию

   может их тоже напишем как «равнозначные» (ц) ? Википедия — не словарь. О том что вариант о котором вы говорите был вообще зачем-то помещен в референс, и, по сути - отсутствовал в определении, я уже помолчу.

2. «авторы» SVN и «разработчики» которые пишут о том как хорош SVN в референсах следом. Предложите вариант, который будет более точен и не будет искажать истины.
3. это вольная перефразировка оригинального «программа разработана специально для замены[3][4] устаревшей[5]системы CVS». А победа SVN, это та гипотетическая материя, из-за которой CVS с какого-то перепугу назвали «устаревшей». Предложите вариант, который будет более точен и … далее по тексту выше.
4. если мы сказали о недостатках CVS, нужно сказать и о недостатках SVN — свободной, несовместимой с CVS (на замену которой претендуют разработчики), реализации некоторых функций и нереализованных возможностях («недоработках»; потому что в отличии некоторых by-design недостатков CVS, коих для SVN мне не известно, их проше доработать).
5. SVN — не новая версия CVS, а совершенно суверенное поделие, и посему она — всего лишь конкурентная система. Оставьте филосовские лекции об устаревании и тлене. CVS — старая система (как, скажем Юникс), но устаревшей она станет только тогда, когда ее будет невозможно применять по назначению (и избавьте меня от реплики типа «CVS уже невозможно применять» — применяли, применяют и будут применять), как например упомянутый Windows 1.0 нельзя применять по причине отсутствия в наличии вменяемого пользовательского софта «сверху» и ОС «снизу» этой оболочки (а также плохой поддержкой последней современного оборудования) у CVS — ничего похожего. Так что «устаревший» это POV (уважаемых референсируемых персон), а примененная неявно в виде «устаревшей[6]» (да еще со ссылкой на полярный источник) — махровый ярлык. Вы лично можете выбирать любую систему, можете бесконечно описывать действительные и мнимые преимущества, но факты остаются фактами. Старая (долго развивавшаяся и используемая) — да, ненавороченная и не имеющая некоторых (некритических) фич — да, менее производительная — да, с серьезными ошибками, допущенными при разработке — да, но до устаревания несмотря на всю прореферированную из статьи пургу, CVS еще далеко, пока она успешно и активно используется и даже развивается, пусть и медленнее чем хотелось бы. Не бегите впереди паровоза.
6. Повторюсь. Инструменты успешно используемые хоть сколько нибудь широким кругом пользователей (а не энтузиастами винтажа) устаревшими без существенных оговорок названы быть не могут. И перечитайте выше про пургу. Статья должна отражать реальность, а не полярную точку зрения.
7. во-первых, в таких АИ нет необходимости, во-вторых о CVS вполне хватает старых статей и мануалов, да и для чего такие публикации могут быть АИ ? Статьи о Subversion и не могут говорить иначе, цитируя мануал SVN. Но ссылки, кстати, можете привести, я такие издания (например «Unix hater handbook») коллекционирую.

В завершение, добавлю, что, как это уже замечали ранее, было бы неплохо, если в описании Subversion было бы поменьше отсылок к CVS. Grain 19:38, 29 июня 2010 (UTC)

P.S. Тролли сыты :) Grain 19:38, 29 июня 2010 (UTC)

На этот раз отвечаю кратко по пунктам:

1. Утверждение «англ. subversion - подверсия» в вашей правке ложно, ибо такого значения слово subversion не имеет. Вместо того, чтобы приводить акушерские значения слова version (о котором речь вообще не идет), лучше посмотрите значения subversion.
2. Авторы Subversion НЕ позиционируют CVS как устаревшую. Это вы приписываете им сами.
3. АИ о «гипотетически неизбежной победе Subversion над CVS» не приведены, так что это заявление - ВП:ОРИСС
4. (уже поправлено)
5. Утверждение об устаревании базируется на АИ. Поэтому, пожалуйста, подкрепляйте свои утверждения источниками, а не разбрасывайтесь общими словами.
6. Вы базируетесь на своем собственном толковании термина. Я базируюсь на общепринятом.
7. Опять общие слова. Жду АИ (которые бы рекомендовали устанавливать и исползовать CVS).
8. (дополнительный пункт) Вы продолжаете вносить правки с сомнительными формулировками:
   • [7]. Вы удалили утверждение о том, что SVN свободен от ряда недостатков CVS (а это чистая правда: в SVN есть атомарные фиксации, наборы изменений, переименования без потерь истории и т.д.). Вашу мотивировку «если мы не пишем о недостатках SVN, тогда не надо упоминать и недостатки CVS» я вообще не понимаю: во-первых, мы пишем о недостатках SVN, во-вторых, на каком основании вы запрещаете писать о недостатках CVS (ведь цель SVN - быть заменой CVS, свободной от его недостатков)?
   • [8] вы заменили нормальную формулировку на слово, которого вообще нет в русском языке.

Итог: я отменяю ваши проблемные правки, но в утверждение об устаревании добавляю "по мнению некоторых источников". После этого прошу по всем спорным моментам предварительно достигать консенсуса в обсуждении.--Кae 08:38, 30 июня 2010 (UTC)

1. вы бы еще медицинский словарь посмотрели, честное слово :) и вообще, слова полученные в результате тривиального словообразования в словарь могут не заноситься, для этого существуют словарные статьи для приставок, суффиксов и т. п.
2. одна из статей написана разработчиком SVN
3. об этой формулировке я все сказал
4. -
5. не вижу ни единого хоть сколь-нибудь авторитетного источника - статья разработчика, руководство по инсталляции SVN, и статья о CVS с POV-припиской о том что она устарела. Вот теперь какие источники авторитетны ... мдя, у меня нет слов.
6. А давайте вдумаемся в вашу формулировку. Она включает три критерия:
   1. сложности с запчастями и дополнительными модулями. Запчасти не при делах, а модули — вопрос спорный, иные проекты умирают именно под тяжестью модулей. CVS безусловно не помешали бы некоторые фичи (их можно с натяжкой приравнять к модулям) но в целом возможности CVS неплохо сбалансированы — часть возможностей реальизовано, часть можно достигнуть хаками.
   2. сложности в нахождении специалистов, умеющих эксплуатировать или ремонтировать/исправлять данное оборудование/ПО, ремонтами можно с натяжкой назвать патчи; специалистов по эксплуатации — полно, на CVS работают как минимум три крупных проекта — NetBSD, OpenBSD и FreeBSD (последний параллельно использует SVN), другие юникс- (и не только юникс) системы включают CVS если не в стандартную установку, то в пакеты, под остальные системы CVS можно найти или купить. Все обнаруженные дыры GNU CVS оперативно патчатся если не GNU, то разработчиками тех же NetBSD, OpenBSD и FreeBSD.
   3. сложности во взаимодействии с другим оборудованием/ПО подобных сложностей также нет — в Юниксе редко ломают старое в процессе изготовления нового.

   Итого, можно с натяжкой найти признаки лишь одного из трех критериев, неужто вы находите в CVS их все ?

7. по этому вопросу я уже высказался. вы исповедуете заведомо ложные критерии, посему я нахожу данный поиск бессмысленным.
8. \
   • после вашей правки, фраза стала говорить недостатках CVS и умалчивать о недостатках SVN, создавая у читателя ложное ощущение что SVN идентична CVS и отличается только в лучшую сторону, что не соответствует истине. Такое отклонение от NPOV недопустимо, и три мои правки в этом абзаце создавали сбалансированное нейтральное утверждение. Описание недостатков «где-то там внизу» совершенно недостаточно — нейтральность определения (брифинга статьи) должна быть сбалансирована прямо в самом определении.
   • во первых, вы опять искали в словаре слово полученное в результате словообразования. А Яндекс это слово знает — «ресурсозатратный» — 45.000 вхождений, «нересурсозатратный» — 56 вхождений. Мне это слово тоже не очень нравится, вероятно «нересурсоемкий» (11.000 вхождений) было бы лучше, но оно всяко лучше просто чудовищной кальки «„дешёвые“ операции».

Последняя версия более или менее нейтральна, хотя я мне ближе английская версия. Мы и обсуждаем. Несколько мешает только автопатруль, я бы предпочел вносить изменения в нестабильную версию (или иметь возможность снимать флаг c ранее патрулированной версии) Grain 13:40, 30 июня 2010 (UTC)

По поводу пункта 8.1 я создам новую тему обсуждения, чтобы не захламлять эту; здесь только об устаревании. Пункт 8.2: если 56 вхождений, значит слова такого нет. Потому, что любой неологизм наберет несколько десятков употреблений, например фтапарат - 156 вхождений.--Кae 19:39, 30 июня 2010 (UTC)

Отвечаю по поводу пункта 6. Вы как-то странно расписали эти пункты. Вот

1. сложности с запчастями и дополнительными модулями. Ряд проектов, связанных с CVS, перестали развиваться: мне известны SmartCVS, CVS Monitor. Многие проблемы CVS не исправляются и никогда не будут исправлены. Важных фич (наборы изменений, атомарные фиксации и т.д.) нет и не будет никогда.
2. сложности в нахождении специалистов, умеющих эксплуатировать или ремонтировать/исправлять данное оборудование/ПО. Несомненно, специалисты будут, пока не умрет поколение. Но по мере миграции с CVS (заметим, на CVS никто не мигрирует) и уменьшения популярности CVS количество людей, хорошо его знающих, неуклонно уменьшается. Три *BSD столпа могут хоститься на CVS хоть вечность, но это количества специалистов реально не прибавит.
3. сложности во взаимодействии с другим оборудованием/ПО. Новые хостинг-проекты не предоставляют хостинг CVS (assembla.com, code.google.com и т.д.). Вот это порадовало: [9]. Старейший CVS-хостинг sourceforge.net предоставляет CVS, но рекомендует использовать что-нибудь поновее (!!!) [10] — одного этого достаточно, чтобы поставить точку в спорах об устаревании CVS.

Итак, все три проблемы в наличии. Заметьте, ваше описание (перечитайте его еще раз) по этим трем параметрам сводится к следующему: при использовании CVS, конечно, возникают определенные проблемы, но ведь его использовать можно!!!. Вот это и есть устаревание: пользоваться-то можно, но возникает все больше проблем при сопровождении [11]. А если перейти на современную систему, то эти проблемы пропадают.--Кae 21:13, 30 июня 2010 (UTC)

Ваши представления о том что есть и чего нет в языке (как в русском и так и в английском) просто шедевральны в своей неправильности, но мне пофигу — вам с ними жить :). По пунктам вы делаете сплошные натяжки - не надо рассматривать CVS с позиции сравнения, устаревание понятие абсолютное, а не сравнительное. Отсутствие необязательных, не влияющих на работу, (или даже желательных) фич и не является признаком устарелости, как не являлось 5-10 лет назад. Хостинги это момент интересный, наиболее важный из всего что вы говорили выше (несмотря на то что серьезные проекты хостятся все-таки на собственных серверах), но для безусловного утверждения все-таки не вполне достаточен. Grain 17:12, 2 июля 2010 (UTC)

Прекратите бросаться пустыми словами и говорите конкретно, в чем «шедевральность неправильности» моих представлений (и желательно со ссылками на АИ). --Кae 10:23, 3 июля 2010 (UTC)

В чем, на мой взгляд, вы не правы (в лингвистическом плане) я подробно описал ранее, а вести аргументированную разъяснительную работу не имею времени. За «шедевральность» прошу прощения, ваши представления меня сильно удивили. Что же до предмета обсуждения, то в одну кучу с актуальными критериями устаревания вы сваливаете совершенно не относящиеся к вопросу популярность, количество фич (совершенно непоказательное, если не сказать больше) и их спектр, темпы развития проекта и т. п.

P.S. И ради бога, замените эти уродливые выражения со словами дешёвый/дешёвые. Это слово в словаре, конечно есть, но в данных случаях оно выглядит как переведенное Prompt-ом. Grain 17:47, 2 июля 2010 (UTC)

Термин «Дешёвые» операции убирать не буду, ибо он совершенно уместен, т.к.

1. слово существует
2. его точный смысл разъяснен в том же предоложении
3. термины дешёвый/дорогой(дорогостоящий) очень широко применяется при описании затратности алгоритмов.[12][13] --Кae 10:23, 3 июля 2010 (UTC)

Хорошо, помыслю на досуге, но сдается мне что это жаргон или узкоспециализированный термин типа жадный алгоритм. Grain 13:27, 3 июля 2010 (UTC)

О недостатках CVS и Subversion

Выше в обсуждении Grain сказал следующее:

после вашей правки, фраза стала говорить недостатках CVS и умалчивать о недостатках SVN, создавая у читателя ложное ощущение что SVN идентична CVS и отличается только в лучшую сторону, что не соответствует истине. Такое отклонение от NPOV недопустимо, и три мои правки в этом абзаце создавали сбалансированное нейтральное утверждение. Описание недостатков «где-то там внизу» совершенно недостаточно — нейтральность определения (брифинга статьи) должна быть сбалансирована прямо в самом определении.

Очевидно, речь идет о каких-то свойствах систем, по которым SVN хуже, чем CVS. Хотелось бы поподробнее узнать, в чем же CVS выигрывает при сравнении с SVN.--Кae 06:27, 1 июля 2010 (UTC)

Именно. К сожалению, я не знаком с SVN близко, и не знаю его глубинных проблем. Но навскидку можно сказать следующее:

• Subversion недостаточно совместим с CVS, который должен заменять (согласно project goals)
• CVS в отличии от Subversion не несет на себе внешних функциональностей — все внешние соединения осуществляются через другие стандартные программы (то что называется Unix-way — не плодить сущностей), программа встроена в существующее окружение, а не создает собственного.
• как следствие предыдущего пункта Subversion зависит от большого числа внешних библиотек, что затрудняет его установку и сопровождение (пакаджи упрощают жизнь, но всех граблей не исправляют)
• Количество фич в Subversion, конечно, впечатляет, но создается впечатление что некоторые из них — попросту лишние (например CVS обходится только тегами/ветками, а в SVN зачем-то сделаны еще и метки). Любой проект должен придерживаться принципа KISS, иначе он рискует погибнуть в глюках, любой интерфейс и любая фича должны добавляться только если они действительно необходимы. Grain 17:42, 2 июля 2010 (UTC)

Тема преимуществ CVS над Subversion не раскрыта:

1. Никто не ставил цели сделать Subversion совместимым с CVS. См. первое предложение здесь. Кроме того, Subversion более совместим с CVS, чем CVS с Subversion просто потому, что конвертор хранилища CVS->SVN существует, а SVN->CVS — нет.
2. Не понял ничего. Можете указать конкретные преимущества CVS?
3. Если админ не может поставить Subversion, то нужно менять админа. Subversion тут ни при чем.
4. Ваша логика какая-то противоестественная. Вы утверждаете, что чем больше фич, тем хуже. Есть мнение (и не только мое), что гораздо легче не использовать существующую ненужную фичу, чем использовать нужную, но не существующую :-). (Я думаю, вам должна понравиться система RCS — там и фич, и глюков еще меньше).

Вообще, если вы «не знакомы с SVN близко», то лучше познакомиться, прежде чем делать какие-либо утверждения. Я говорю без всякой иронии, вам должно понравиться. Или еще лучше переходите сразу на распределенные. --Кae 11:27, 3 июля 2010 (UTC)

• С SVN я знаком достаточно чтобы говорить то что говорю, и не надо меня одергивать и искажать смысл сказанного.
• реплика противоречащая ВП:ЭП удалена, приношу извинения Grain 10:21, 6 июля 2010 (UTC)
• англ. to be a better CVS из вашей ссылки переводится как «быть „хорошим CVS“», а не «быть лучше чем CVS» (это бы звучало как англ. to be a better than CVS), так что наверно ставили. А насчет конвертера это вообще передергивание. Grain 12:20, 3 июля 2010 (UTC)
• P.S. И речь шла скорее о недостатках SVN чем о преимуществах CVS. Grain 12:29, 3 июля 2010 (UTC)

P.P.S. Немного поясню.

• Гонка за количеством фич — зло, это должно быть очевидным, множество программ со временем становятся неюзабельными (по различным критериям) и/или нестабильными из-за втюхивания в них множества новых возможностей (зачастую — ненужных или редкоиспользуемых). Возможности программы должны быть ортогональны — чтобы делать максимум задач минимумом фич, в том числе по максимуму использовать возможности окружения, если это возможно. Grain 10:21, 6 июля 2010 (UTC)

У меня возникло ощущение, что дискуссия про SVN и CVS связана с недостаточным раскрытием вопроса о целях проекта по созданию Subversion. Имеющееся утверждение "Инициаторы проекта хотели создать свободную систему управления версиями, в основном похожую на CVS, но лишённую её ошибок и неудобств.", очевидно, не достаточно. Прошу основного автора статьи раскрыть эту тему полно. Чтобы стало понятно, почему авторы SVN ну никак не могли использовать имеющееся ПО и предпочли создать новое. Kmorozov 05:54, 7 июля 2010 (UTC)

Приведенное вами утверждение, на мой взгляд, достаточно полно характеризует цель. Что касается улучшений SVN по сравнению с CVS, то они очень подробно расписаны в секции Subversion и CVS. Это сравнение показывает, «почему авторы SVN ну никак не могли использовать имеющееся ПО и предпочли создать новое». Если считаете, что этого недостаточно, то сформулируйте конкретнее, чего надо добавить. --Кae 13:29, 7 июля 2010 (UTC)

Имелось в виду, что несовершенство чего-то не обязательно мотивирует на создание замены, а возникает из более чёткой потребности. Не стали же разработчики SVN начинать проект просто из-за эстетического несогласия с авторами SVN. Возможно, у них были какие-то свои потребности (например, они разрабатывали какую-то другую сверхсложную задачу, которую с CVS было не решить), может у них была плодотворная бизнес-идея, как обогатиться на SVN. Или это действительно просто энтузиасты-альтруисты? Нельзя ли это прояснить? Kmorozov 03:55, 8 июля 2010 (UTC)

Все дело в степени «несовершенства». У CVS оно настолько велико, что создает значительные проблемы при использовании. CVS неудобен не только на сверхсложных задачах, но и вообще на любых. Вот наиболее серьезные недостатки CVS:

• Нет атомарных фиксаций. Например, отправляешь изменения в 10 файлах и после отправки 5-го пропала сеть. В результате опубликованы не все изменения. Проект сломан (пока не откатишь или не выложишь все).
• Нет изоляции фиксаций. Например, кто-то фиксирует много файлов с 10:00 до 10:15, а я делаю checkout в 10:05. В результате я захвачу только часть его изменений. В результате у меня рабочая копия в несогласованном состоянии (т.е. не построится).
• Нет нормального переименования файлов и директорий. Т.е. если мы переименовываем что-то, то его история до момента переименования у нового объекта отсутствует! Это крайне затрудняет рефакторинг кода.
• Нет наборов изменений. Например, мы видим некоторое изменение в истории файла и хотим узнать, какие файлы еще были изменены в той же фиксации, чтобы полностью понять смысл изменений. Так вот, в CVS нет стандартного способа узнать всю группу файлов, затронутых в фиксации.
• Нет простого способа указать на состояние репозитория (например, «бери состояние *****, оно гарантированно рабочее!»). Нужно или ставить метку (долго и неудобно), или указывать точное время (неудобно и путаница с часовыми поясами).

Есть и другие, более мелкие недостатки. Но описанных выше вполне достаточно, чтобы задуматься над созданием чего-то более совершенного. Вот так и создали Subversion. А что касается бизнес-модели CollabNet Inc, то они зарабатывают на поддержке, обучении и т.д. --Кae 11:15, 8 июля 2010 (UTC)

Это бы объясняло, если бы в природе существовала ровно 1 система контроля версий. Но их же довольно много? Это примерно, как если бы мне не нравился OpenOffice (как будто только с ним и можно соревноваться) я бы начал делать свой офис. Это же дорогой процесс, человеко-годы, а результат не гарантирован. Kmorozov 11:49, 8 июля 2010 (UTC)

Именно так и было: на тот момент (2000 год) существовала ровно 1 свободная система управления версиями (не считая совсем допотопных типа RCS). Были очень хорошие системы (Rational ClearCase, Perforce), но они проприетарные. Поэтому вопрос о создании хорошей свободной системы стоял остро. --Кae 12:19, 8 июля 2010 (UTC)

Теперь я понял причину такого упорного сопоставления именно с CVS. Но из текста статьи никак не следует, что именно свободность является главным критерием, при сравнении конкурирующих продуктов и что не-свободные как альтернативы не рассматриваются. Kmorozov 12:43, 8 июля 2010 (UTC)

Ок, попробую описать это более явно. --Кae 12:49, 8 июля 2010 (UTC)

Хм.. хотел написать, но вроде в секции История уже нормально написано. Внесу только небольшие правки туда. --Кae 10:57, 9 июля 2010 (UTC)

Нет, дискуссия возникла из-за того что статья не придерживалась нейтральной точки зрения и без каких-либо оговорок определяла конкурентную систему «устаревшей». Быть может, тема истории проекта требует более полного раскрытия, главное чтобы не в определении, которое и так перегружено. Grain 08:19, 7 июля 2010 (UTC)

Давайте не будем начинать все сначала. Я привел в статье 3 АИ об устаревании. Если у вас есть АИ об актуальности CVS — то приведите их. Если нет, то и говорить не о чем, все уже сказано. --Кae 13:32, 7 июля 2010 (UTC)

Что касается «игры слов»

Необходим пруфлинк о том что название Subversion было изначально задумано или когда-то явно осмысливалось разработчиками как игра слов подверсия/свержение, а не было придумано горе-переводчиками с медицинскими словарями или надумано третьими лицами. В противном случае утверждение о том что «название является игрой слов», вероятно ложно. Grain 08:38, 3 июля 2010 (UTC)

На одно подтвержение наткнулся сам, добавляю. Grain 08:48, 3 июля 2010 (UTC)

АИ для подтверждения игры слов не требуется (точнее, достаточно словаря, доказывающего наличие нескольких значений). Причина в том, что для наличия игры слов совершенно не нужно, чтобы эта игра была задумана с самого начала. Простой пример: по поводу фамилии Блюхера насочиняли анекдотов, в которых обыгрывается второй смысл частей слова (в точности как у Sub-version). Игра слов налицо. Будем искать пруфлинк о том, что предки Блюхера это задумали изначально? Наверное, не стоит. Также и с Subversion. Смысл Subversion один, смысл комбинации sub+version другой. Все, игра слов понятна любому, кто может пользоваться словарем. Или лучше вообще убрать термин "игра слов" --Кae 15:21, 7 июля 2010 (UTC)

Я не понял, говоря о "медицинских словарях" вы хотите поставить под сомнение, что слово правомерно раскладывать на sub и version? Потому что значение "свержение, низложение" Вы найдёте в любом словаре толще карманного. В английской версии об этом, естественно, не говорится, потому что игра слов очевидна любому грамотному носителю языка. Если Вы думаете, что слово существует только в словарях и не используется, то вот Вам пример как раз из английской Википидеи: Albanian Subversion. В гугле тоже можно найти примеры, если правильно поискать. Итак, в словарях указано определённое значение слова, это слово активно используется носителями языка именно в этом значении и оно использовано одним из хорошо образованных носителей языка. Неужели Вам нужен пруфлинк, что он использовал слово именно в этом значении?! А если кто-то скажет "белое", Вы не потребуете пруфлинк, что он имел в виду не чёрное? --SergV 16:50, 7 июля 2010 (UTC)

Поясняю (через месяц, но как могу). Нет, как раз наоборот, я пытаюсь отстоять значение названия «подверсия» как исключительно основное (вопреки стремлению Участника Кae поставить на это место нелепый в компьютерном ключе омоним «свержение»). Я считаю очевидным что название программы в первую очередь необходимо переводить функционально, и в этом ключе «Subversion» однозначно переводится как «подверсия». А обращение Кae за переводом этого слова в словарь общей лексики (вместо ИТ-словаря) столь же неправильно как перевод «subversion» по медицинскому словарю (упоминание последнего — метод ad absurdum, а также напоминание об известных ошибках и стёбах — переводе мануалов и иных компьютерных тестов с помощью авто-переводчика с использованием неподходящих словарей — общей лексики или медицинского). Grain 21:36, 31 июля 2010 (UTC)

Кстати говоря, а вы можете привести пруфлинк, подтверждающий, что слово subversion присутствует в IT словарях и однозначно переводится как подверсия? --SergV 06:32, 1 августа 2010 (UTC)

sub- + version (см. раздел «Компьютерный»). Как я уже говорил выше, составные слова не обязаны присутствовать в словарях, чтобы иметь право на существование. Достаточно наличия словарных статей для корней и приставок/суффиксов и правил словообразования. Grain 12:11, 2 августа 2010 (UTC)

Отлично. Есть приставка "по" и слово "мойка". Что, по правилам словообразования, значит слово "помойка"? --SergV 12:48, 2 августа 2010 (UTC)

В общем смысле «помойка» = «мытье», однако в узусе помойкой называют место для помоев (буквально: грязной воды, а в узусе — мусора). Grain 13:03, 2 августа 2010 (UTC)

И вы ещё говорите о здравом смысле. Вы придумали какой-то свой язык, в котором помойка значит мытьё, а subversion - подверсия и требуете доказательств того, что для большинства людей это не так. --SergV 08:21, 3 августа 2010 (UTC)

А я чего-то требую ? Вы спросили — я ответил, чья вина что наши мнения расходятся ? А пример был ваш, к вам и претензии :) Grain 20:10, 3 августа 2010 (UTC)

Я понимаю наличие у слова «subversion» значения от корня subvert и очевидность (для носителя) игры слов подверсия-свержение, но сам факт того что авторы намерено использовали и подразумевали эту игру слов (о чем рассказывает статья) по-моему требует пруфлинка (иначе мы дойдем до совершенно нелепых толкований, например «Unix» через латинское слово означающее «евнух», реальный, между прочем, пример из методического пособия !). Grain 21:36, 31 июля 2010 (UTC)

Subversion не латинское слово, а английское, с латинским корнем. С моей точки зрения, как раз утверждение, что несколько носителей английского языка задумали свергнуть CVS и в качестве названия проекта случайно выбрали слово "свержение", не подозревая, что оно значит. Иначе можно дойти до абсурда и требовать доказательств, что в названии текстового процессора слово word означает "слово", а не 16 бит, как написано в IT-словарях. --SergV 06:51, 1 августа 2010 (UTC)

Игра слов на «свержение», разумеется, неслучайна и тому есть пруфлинк (который в данный момент откатили), если вас не убеждает моя уверенность в очевидности «подверсии», то (опять-таки повторюсь) посмотрите на логотип — на нем приставка SUB отделена от VERSION цветом, из чего я лишний раз делаю вывод, что название образовано от version, а не от subvert. Пример с Word несколько неудачен, потому что в отличии от Subversion это прикладная программа, и названа она в прикладном же ключе. И в любом случае, в осмысливании (при переводе) названий нужно привлекать здравый смысл, который в данном случае оказался изнасилован (утверждением что программа управления версиями названа от значения «свергнуть», а не от значения «версия»). Grain 12:11, 2 августа 2010 (UTC)

По-моему, это вы грешите против здравого смысла. В статье говорится о вполне очевидной игре слов, использованной в названии. Ни о каком "переводе" названия речь не идёт. --SergV 12:48, 2 августа 2010 (UTC)

Значит реплика Subversion англ. subversion — «свержение» или «подрывная деятельность». В то же время, слово можно перевести как подверсия: англ. Sub- — «под-» + version — «версия» по-вашему не перевод ? (тот факт что перевод снесен в сноску ничего не меняет). Grain 13:03, 2 августа 2010 (UTC)

Естественно, это не перевод. Это объяснение игры слов для читателей русской Википедии, которые не обязаны знать английский. Вы так и не привели доказательств того, что слово можно перевести как "подверсия". Ни одной ссылки, ни на словари, ни на использование носителями языка. Выделение цветом в логотипе как раз подчеркивает необычность такого прочтения. Если бы слово регуляроно использовалось в значении "подверсия", в выделении не было бы необходимости. Никто, впрочем, не отрицает ни возможности такого прочтения, ни намека на слово "версия" в названии. --SergV 08:21, 3 августа 2010 (UTC)

Ну приехали :) Я — не я и хата не моя. Бог с ней с версией (прости, господи), перевод-то вам чем не угодил ? «правильный», сугубо словарный :) Grain 20:10, 3 августа 2010 (UTC)

Хоть в отношении устаревания CVS, дискуссия и дала положительные результаты. Я нахожу отдельные решения (напр. перевод в сноске !), действия (напр. моя последняя переработка определения была им по сути полностью откачена в пять правок) и убеждения (напр. «слова не существует если его нет в словаре») Участника Кae неправильными и вредными для данной статьи. К сожалению я не имею времени чтобы составить необходимую оппозицию (привлечь внимание других специалистов в этой теме и т. п.) Grain 21:36, 31 июля 2010 (UTC)