Обсуждение:Subversion

Архивы обсуждений

• Август 2005 - август 2010

Под-папки и SVN 1.7

Раздел "Фиксация изменений / Рабочая копия". Он разве не устарел ? По другому это описывали как pollution, типа SVN загаживает ВСЕ папки своей служебной инфой. И вроде бы в 1.7 теперь служебная инфа хранится только в корневой папке в Pritine SQLite DB. Но... тогда автоматически получается, что простое копирование подпапки "наружу" не создаёт новую рабочую копию, а вырывает эти файлы из SVN. Also: http://ru.wikipedia.org/w/index.php?title=Subversion&diff=43205139&oldid=43048654 85.90.120.180 12:49, 5 июля 2012 (UTC)

Ошибки в правке секции "Адресация состояния хранилища"

Я откатил правку [1], т.к. в ней допущен ряд смысловых ошибок, а именно:

• ветви и метки в Subversion не являются размерностью хранилища как в CVS — в CVS метки не являются размерностью хранилища.
• в CVS ветви и метки Subversion являются объектами одной природы — в CVS метки и ветви не являются объектами одной природы.
• как и в CVS ветви и метки Subversion являются объектами одной природы и различаются лишь соглашением о том что в метки, в отличие от ветвей не вносится изменений — в CVS в метки невозможно внести изменения. В Subversion — да, можно.
• но менее гибким, нежели использование меток — нельзя напрямую сравнивать ревизии и метки (теплое с мягким) по "гибкости", т.к. у этих сущностей в Subversion очень разное назначение.

Вы лучше скажите, что вам не понравилось в существующем тексте абзаца? --Кae 10:57, 18 сентября 2010 (UTC)

К вам встречный вопрос: почему вы считаете нормальным выполнение полного отката, вместо того чтобы исправить имеющиеся в моем варианте "фактические ошибки" ? Grain 14:31, 18 сентября 2010 (UTC)

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

• очевидное и неоднозначное: В CVS для указания на некоторое состояние хранилища (например, стабильное состояние исходного кода) используются метки. очевидное, потому что в SVN метки используются так же, а неоднозначное, потому что «стабильное состояние» может быть как фиксированным таргетом, так и веткой. В CVS просто так организуются ветки — установкой тегов.
• ложное утверждение: Использование меток в Subversion подобным образом вызовет некоторые неудобства (прежде всего, невозможность дальнейшей работы прямо от метки). Метки SVN аналогичны веткам, и поэтому, при желании могут быть использованы как moving target (ветки). Это противоречит лишь исключительно рекомендательной идеологии разработчиков, что не есть «невозможно» (да и то, метку можно вполне легитимно перенести в каталог веток).
• неподтвержденное утверждение: Правильным способом указания состояния в Subversion является номер ревизии..

я нашел время чтобы переписать раздел (так как в существующем виде его можно было удалить за бессмысленностью). Последнее утверждение я оставил, запросив для него АИ. Ложное утверждение о метках я заменил на верное (об этом ниже). Первое утверждение я не стал уточнять за отсутствием необходимости, зато осветил действительно важный момент о необходимости структурирования репозитория (которого CVS не требует). Grain 14:57, 18 сентября 2010 (UTC)

Теперь по пунктам:

1. В CVS у файла три координаты — тропа, тег и версия, вы сами называете теги (точнее ветки, что одно и то же) «третьим измерением», как понимать ваше непринятие термина «размерность» (оно же «измерение») ?
2. Насколько мне известно (опровергните меня если можете), ветки в CVS организуются тегами (метками), то есть что метки (теги), что ветки — частный случай одной фичи. Как и в SVN, что я и указал в своей редакции.
3. Не понимаю. Переключаем рабочую копию CVS на тег (метку) и изменяем файл и комитим новую версию — «метка» изменена. CVS не позволяет только "переставить" тег в другое место (или заменить его), это да, но уточнять это при миграции CVS->SVN излишне.
4. Ревизии и метки сравнили ВЫ, сказав что ревизии «правильней» меток, я вас лишь перефразировал.

Grain 15:15, 18 сентября 2010 (UTC)

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

1. В CVS у файла три координаты — тропа, тег и версия. Нет, координаты такие: путь(=тропа?), ветвь, версия. Если говорить еще более точно, то независимых координат всего две: путь и версия (ветвь не является независимой координатой, т.к. идентификация ветви содержится в версии). А тег — это алиас для пары ветвь+версия, т.е. размерностью тег не является. Не отождествляйте тег и ветвь в CVS — это разные сущности!
2. Нет. См. предыдущий пункт. Возможно, вас вводит в заблуждение тот факт, что в CVS имена ветвей и тегов как бы в одном пространстве имен (некоторые команды принимают в одном параметре имя либо тега, либо ветви). Заметьте также, что чекаут по имени ветви даст головную ревизию ветви, а чекаут по тегу даст фиксированную ревизию (ту, на которую наложена метка).
3. Переключаем рабочую копию CVS на тег (метку) и изменяем файл и комитим новую версию — «метка» изменена. Нет, метка не изменена. Зафиксирована новая головная ревизия помеченного файла. А метка осталась как есть. Сделайте чекаут метки еще раз — получите метку в том же самом неизмененном виде. А вот в SVN коммит в метку изменит саму метку, т.к. SVN-овская "метка" не содержит номера ревизии. CVS не позволяет только "переставить" тег в другое место (или заменить его) — как раз позволяет: командой cvs rtag удаляем старый, командой cvs tag накладываем новый.
4. (Вы несколько исказили смысл перефразировкой, ну да ладно, перепишем)

А вообще в секцию "Адресация состояния хранилища" я вкладывал такой смысл: в CVS состояние адресуется метками либо датой, а в Subversion - ревизией (но не меткой: метка есть копия, а не адрес состояния). Эта секция нужна потому, что пользователи, перешедшие с CVS на Subversion, часто пытаются применять метки по CVS-овски, а это неправильно.--Кae 19:00, 18 сентября 2010 (UTC)

Перечитал мануал. Вы правы, ветки это особые теги, создаваемые с ключом -b, только я почему-то этого не помню, что весьма странно, т.к. ветки я использовал неоднократно.

Сделал тест в пункте 3. Новая версия не попала ни в тег ни в транк - коммит выдал ошибку :)

$ cvs -d user@host:/cvs import test NOBODY TEST
$ cvs -d user@host:/cvs get test
$ cd test
$ echo one > test.txt
$ cvs add test.txt
$ cvs commit
RCS file: /cvs/test/test.txt,v
done
Checking in test.txt;
/cvs/test/test.txt,v  <--  test.txt
initial revision: 1.1
done
$ cvs tag test_tag
cvs tag: Tagging .
T test.txt
$ cvs up -r test_tag
cvs update: Updating .
P test.txt
$ cat test.txt
one
$ echo two > test.txt
$ cat test.txt
two
$ cvs commit
cvs commit: Examining .
cvs commit: sticky tag `test_tag' for file `test.txt' is not a branch
cvs [commit aborted]: correct above errors first!
cvs commit: saving log message in /tmp/cvsUzgK8f

еще посмотрю под другой версией CVS, но принцип ясен. Grain 20:43, 18 сентября 2010 (UTC)

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

И я что-то не совсем понял насчет rtag — это всего лишь хранилищная версия tag, а удаление и перемещение тега делается ключами -d и -F, соответственно. Grain 22:01, 18 сентября 2010 (UTC)

Почему тут вообще cvs?

Может Вам перебраться в ветку обсуждения CVS?

CVS (Concurrent Versions System, «Система Одновременных Версий»)

Subversion[1] (также известная как «SVN»[2]) — свободная централизованная система управления версиями, официально выпущенная в 2004 году компанией CollabNet Inc.

Цель проекта — заменить[3][4] собой распространенную на тот момент систему Concurrent Versions System (CVS), которая ныне считается устаревшей[5][6][7].

P.S. Хотел почитать про svn commit, а здесь такоОее...

02:54, 28 сентября 2011 (UTC) статья мне ужасно не нравится, отсутствием примеров реального использования программы svn, как то, commit, реальный пример, ГДЕ ОН? У нас есть sourgeforge, есть code.google.com, есть куча других репозитариев, поддерживающих как mercurial, так и cvs, почему нельзя зделать рабочие примеры, где чтящий этот документ лишь заменит пароль и логин на свои и будет радоваться. Те же комментарии оставил бы под статьями об одноимённых системах управления версиями, но уйду в en.wiki, и остальные пойдут за мной.

Изоляция транзакций

Разберем формулировку:

• Изоляция. Если один пользователь фиксирует изменения множества файлов единой транзакцией, то другие пользователи не могут увидеть такого состояния хранилища, в котором часть файлов зафиксирована, а часть — не зафиксирована. Другими словами, с точки зрения пользователей не существует состояния хранилища «в середине» транзакции. Хранилище мгновенно переходит из состояния до транзакции в состояние после транзакции, поскольку новая головная ревизия появляется только когда транзакция уже завершена, а до этого видна только предыдущая ревизия.

1. Отсутствие промежуточных версий репозитория при мультиобъектном коммите и, как следствие, невозможность его «увидеть», это голая атомарность
2. Изоляция это совершенно другое свойство — это отсутствие влияния транзакций друг на друга. То есть «невидимость» полностью сформированного текущего состояния репозитория, если это состояние изменилось параллельной транзакцией. Иными словами, если идти по Вашей формулировке, мало сказать что новая ревизия не видна до завершения фиксации, она становится видна только в новых транзакциях
3. В свете описанного выше, из формулировки можно выкинуть совершенно ненужные упоминания:
   • многообъектности фиксации — количество изменений на изоляцию не влияют
   • невозможности частичной фиксации — это атомарность
   • «мгновенность» перехода от одной версии к другой — это вообще скорее целостность

Хотя ACID, если подумать, дает весьма туманное определение, которое можно крутить и так и эдак ... Grain 22:15, 19 сентября 2010 (UTC)

Update: Хех, судя по английской версии, ACID по умолчанию не предполагает многопользовательского режима, поэтому все с ним связанное одной кучей свалили в «изоляцию». Дополнил формулировку доступом к незавершенной транзакции. Grain 02:20, 20 сентября 2010 (UTC)

Что касается контекста журнального «метки — это не ссылки !». Имелось ввиду что метки это копии, а копии в Subversion — ссылочные и разностные, в общем случае, а в случае меток они просто ссылаются на существующие версии файлов и не содержат никаких изменений. Grain 02:32, 20 сентября 2010 (UTC)

1. Отсутствие промежуточных версий репозитория при мультиобъектном коммите и, как следствие, невозможность его «увидеть», это голая атомарность — Нет, это неправильно. Читаем ACID и рассматриваем пример: человек выкладывает свежие версии кода (много файлов) на расшаренную папку. При каких-либо проблемах (например, недостаточно места) человек записывает сохраненную предыдущую версию кода (т.е. делает откат). В этом примере атомарность есть по определению, а изоляции нет (можно поймать промежуточное состояние).
2. Да
3. по пунктам:
   • количество изменений на изоляцию не влияют — это так, но наша цель — не в том, чтобы написать максимальное неизбыточное определение, а в том, чтобы объяснить понятным языком. И в этом смысле уточнение о многофайловости полезно, т.к. оно описывает понятие в простых, наблюдаемых пользователем терминах (например, в том же CVS можно «увидеть» середину чужого многофайлового коммита).
   • Там слово фиксация следует заменить на изменение и будет правильно.
   • «мгновенность» перехода от одной версии к другой — это вообще скорее целостность — я не согласен. «НЕмгновенность» подразумевает наличие промежуточных состояний, т.е. отсутствие изоляции.
4. «метки — это не ссылки !». Имелось ввиду что метки это копии, а копии в Subversion — ссылочные и разностные. Да, копии — ссылочные и разностные, но там говорилось о содержимом файловой системы. А с точки зрения файловой системы метка именно копия, и ее ссылочную природу никак невозможно обнаружить (разве только по быстроте создания). То, что она на самом деле ссылка, - это просто внутренняя оптимизация системы.

Я поправлю вашу редакцию определения, т.к. она трудно понимаема и содержит 2 непонятных термина («неверная ревизия» и «завершающее атомарное переключение»). --Кae 11:36, 23 сентября 2010 (UTC)

Да, feel free.

1. Хоть в примере с выкладыванием файлов я и не вижу транзакции, там присутсвует, разве что "ACID-атомарность", т.к. во всех остальных применениях атомарными называются операции не нуждающиеся в изоляции. Мои изначальные рассуждения были таковы:
   • атомарность (в том числе по ACID) гарантирует отсутствие «в системе частично зафиксированных транзакций». О частичных транзакциях забыли.
   • многопользовательзовательская работа имплицитно (IMHO) гарантирует неразличимость работы одним или несколькими пользователями, в том числе гарантируя нескольким пользователям все то что гарантировалось одному (включая атомарность). С этой позиции возможность грязного чтения (то есть доступа к незафиксированной транзакции) это довольно неоднозначный speed hack.
   • если принять за данность вышеперечисленное, изоляция позволяет нескольким пользователям работать одновременно либо посредством блокировок для единого экземпляра данных, либо при необходимости, работой каждого пользователя со своей копией. Вспоминать на этом уровне физическую неатомарность транзакции, о которой мы, вроде бы, уже забыли, IMHO, было избыточным.
   • Но это соответствует ACID, который как, впрочем, и любой стандарт (например тот же OSI), одни сущности упоминает избыточно, другие же — неестественным образом группирует в одном тезисе. Так целостность, если вдуматься, требование вовсе не к системе управления данными (для чего призван ACID), а к программисту, пишущему транзакции. В случае же с изоляцией имеет место избыточность — вводя многопользовательскую работу на этом уровне, ACID начинает «продавать» гарантированные ранее свойства транзакции (атомарность, целостность) по второму кругу, только уже в применении к многопользовательской работе, как отдельные уровни изоляции.
   • Но коль мы ссылаемся на ACID, да будет так.
2. -
3. тоже по пунктам
   • изначальная формулировка оставляла впечатление что для однообъектных изменений изоляции не требуется
   • «мгновенные переходы состояния» вообще, плохая формулировка, так как не соотвествует процессу, поэтому необходимы оговорки, типа «с точки зрения пользователя». здесь хранилище работает как стек — мы выкладываем новую версию поверх указателя стека, переставляя сам указатель атомарно (или с блокировкой) в последнюю очередь, поэтому тот кто обращается до завершения не видит изменений.
   • согласен.

Grain 15:32, 25 сентября 2010 (UTC)

К правке от 28.09.2010

Недостатки формулировки:

1. довольно неудачный (просторечный) оборот «увидеть изменения», пользователи вовсе не «смотрят» репозиторий, а работают с ним, получают доступ к нему и т. п.
2. при переформулировке вы потеряли один из уровней изоляции ! «невидимы» не только параллельные незавершенные транзакции, но и параллельные завершенные (то есть пользователь видит одну и ту же ревизию даже если во время запроса репозиторий изменился)
3. ваша формулировка излишне риторична — она трижды описывает одно и то же, разными словами, я думаю нужно обойтись одной четкой, недвусмысленной формулировкой

Grain 13:00, 29 сентября 2010 (UTC)

Добавил альтернативную (третью) версию формулировки в текущую (непатрулированную) версию. Посмотрите, по-моему такая формулировка проще. Grain 12:04, 30 сентября 2010 (UTC)

SVN в интернете

Хотелось бы дополнить статью утверждением, что существует большое количество SVN-хостингов, часто интегрированных с файловыми хостингами типа Amazon S3, однако не владею темой настолько чтобы придать этому утверждению необходимую степень глобального обобщения. Не возьмётся ли кто-нибудь? Kmorozov 07:35, 20 сентября 2010 (UTC)

Утверждение «существует большое количество SVN-хостингов, часто интегрированных с файловыми хостингами» достаточно тривиально, да и хостинги некоторые перечислены ("Публичные хранилища SVN" в конце). Кроме того, если коммерческие хостинги перечислять, то это будет что-то вроде рекламы и их могут удалить из статьи. Так что если добавлять в сатью, то что-то более весомое (что?). --Кae 10:17, 23 сентября 2010 (UTC)

О переводе названия Subversion

Обсуждение на форуме толкования названия subversion как производного от sub-version против толкования как производного от subvert: О переводе названия Subversion Grain 23:35, 2 октября 2010 (UTC) подправлено --Nashev 17:11, 1 июня 2011 (UTC)

Оперативная ревизия (англ. operative revision) и Стержневая ревизия (англ. peg revision).

ИМХО, это весьма корявый перевод. Неужели он устоявшийся? --Nashev 17:18, 1 июня 2011 (UTC)

Вряд ли есть что-то устоявшееся. Все, что у нас есть по переводу терминов - это перевод главной книги о Subversion.--Кae 15:59, 7 июня 2011 (UTC)

"Трудно узнать, в какие метки вошёл файл (то же для директории)."

— это значит, что трудно узнать, какими метками файл (директория) был помечен? --Nashev 17:33, 1 июня 2011 (UTC)

Да. У помеченного объекта нет никакой информации о его метках.--Кae 16:01, 7 июня 2011 (UTC)

Но многие клиенты SVN способны показывать всю историю файла/папки, со всеми её ответвлениями, в том числе ответвления в папки tag. И вроде бы делают они это не сильно напрягая сервер. --Nashev 20:41, 13 июня 2011 (UTC)

Вот потому и "трудно", что нужны дополнительные инструменты. В родном клиенте командной строки нет простого способа (или я не знаю этого способа?) нахождения меток. --Кae 08:59, 14 июня 2011 (UTC)

локальная директория может быть рабочей копией только одной ветки одного репозитория

по поводу отката

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

В VSS я могу множеству разных веток (папок) репозитория назначить одну и ту же локальную директорию в качестве рабочей папки (working folder) и сравнивать/забирать/выкладывать локальные файлы в любую из этих веток, находясь в ней при просмотре репозитория. В SVN так сделать не получится, насколько я понял. Про то и пишу. Что Вам было не понятно, Kae? --Nashev 20:48, 13 июня 2011 (UTC)

А можно узнать, это кто-нибудь ещё отмечает в качестве недостатка Subversion или это ваш ОРИСС? С моей точки зрения, это достоинство, которое гарантирует целостность каждой из веток. --SergV 22:38, 13 июня 2011 (UTC)

Во-первых, я не говорил что это недостаток. Я описывал это как особенность. Вы её будете отрицать? --Nashev 11:54, 14 июня 2011 (UTC)

В Subversion есть команда switch, которая переключает рабочую копию на любую ветку репозитория. По-моему, этой функциональности достаточно на все случаи жизни. Можете привести сценарий, в котором switch не достаточно, а функциональность VSS помогает решить проблему? --Кae 08:47, 14 июня 2011 (UTC)

Про switch почитаю, спасибо. --Nashev 11:54, 14 июня 2011 (UTC)

Почитал. Не понял, может ли switch переключить рабочую папку на другую ветку, не забирая из той ветки отличия в саму рабочую , т.е. не меняя файлов в рабочей папке, а меняя только BASE в своих служебных папках. Ибо --relocate, вроде бы так и делающий, предназначается как я понял лишь на случай смены корневого URL репозитория, и даже BASE не меняет. --Nashev 16:59, 14 июня 2011 (UTC)

может ли switch переключить рабочую папку на другую ветку, не забирая из той ветки отличия — не может. Опять же, вроде бы незачем так делать. Если переключить BASE, а файлы не менять, то разница между старым и новым бранчем будет выглядеть как локальные изменения, и их не отличить от локальных изменений, которые там действительно были. --Кae 17:23, 14 июня 2011 (UTC)

В VSS мёржить ветки (т.е переносить состояние одной ветки в другую) приходится через их локальные копии. Локальных изменений, не отражённх в репозиторий, в этот момент может вовсе не быть. В случае, если собственных изменений в ветке назначения не много, довольно удобно сделать именно общую локальную копию и смотреть/вносить отличия этой копии от обеих папок репозитория, таким образом по сути сравнивая именно эти ветки, но с возможностью подправлять сравниваемое для последующего выкладывания. В SVN можно непосредственно мёржить ветки, так что наверно это не столь актуально... Практика покажет. --Nashev 11:49, 15 июня 2011 (UTC)

слияние при update

Я не понял так же, может ли SVN изменения, выложенные в репозиторий, НЕ мёржить самостоятельно и МОЛЧА в локально изменённые текстовые файлы, а всегда заявлять о конфликте? Потому что если изменения в разных местах исходника, это не значит, что они не противоречат и не конфликтуют по сути, и их не надо мёржить руками. А из статьи следует уверенность, что всегда можно, когда затронуты разные строчки. --Nashev 16:59, 14 июня 2011 (UTC)

Насколько я знаю, нельзя (если вы имеете в виду неявный мерж чужих и своих изменений при update). Даже если бы такая фича и была, то ей бы никто не пользовался - слишком утомительно. Конфликтом считается коллизия изменений в одной и той же строке. И из статьи никакой "уверенности" не следует, просто такова модель работы, принятая в Subvesion. А неужели в VSS нужно руками мержить изменения в разных строках? --Кae 18:40, 14 июня 2011 (UTC)

Да, автоматически забирать из репозитория только изменившиеся строки, а не файлы целиком, умеют только бесплатные юниксовые средства совместной работы, рассчитанные на С-шные исходники. ИМХО, стрёмно автоматически забирать незнамо что, особенно для структурированных и машинно-читаемых текстовых файлов типа XML или RTF. Ведь правки могут конфликтовать логически или структурно, даже если они в разных строках, а система их молча смёржит, и лови эти конфликты потом... Я предпочитаю анализировать всё, что забираю, и VSS этому способствует, а SVN мешает. И если есть возможность заставить SVN запускать во время update процедуру конфликта с ручным мёржем внешней программой при любом изменении файлов репозитория, которые изменены у и меня, то об этой возможности нужно написать. --Nashev 11:49, 15 июня 2011 (UTC)

This project cloaked for me @ VSS

Другая фича VSS — это галочка «This project cloaked for me» у папки репозитория, которая заставляет VSS игнорировать существование той папки и всех её дочерних при в рекурсивных операциях над родительскими папками, и хранится в разрезе пользователей. Это позволяет программистам, например, не ждать сравнения папок с шаблонами и документацией при куда более часто совершаемых ими сравнениях папок с исходниками — в случаях, когда в одной ветке репозитория хранятся папки множества подпроектов каждый со своей обвеской, а нужно сравнить с локальной копией лишь исходнки, но от них всех сразу. Я так понимаю, отсутствие ограничителя рекурсивных операций — это тоже особенность SVN? Как мне её в статье покороче и попонятнее отразить?--Nashev 20:58, 13 июня 2011 (UTC)

Такой ограничитель есть. В Subversion это называется sparse directories. А почему вы решили сравнивать Subversion с VSS? По моему, это здесь совершенно не к месту. --SergV 22:15, 13 июня 2011 (UTC)

А почему б не посравнивать? Это один из конкурентов, сравнивают и с ним в том числе. Почему ж не к месту-то? Кста, спасибо, про sparse почитаю. --Nashev 11:17, 14 июня 2011 (UTC)

Я не против того, чтобы кто-то сравнивал, но зачем это делать в этой статье? Есть гораздо более важные конкуренты, что с ними всеми сравнивать? Сравнение с CVS естественно, потому что SVN написана специально для её замены. В остальном должны быть отмечены особенности, отличающие SVN от большинства других систем. Например, особый подход к организации веток и меток (фактически, их отсутствие). Подробное сравнение с отдельными системами ни к чему. --SergV 18:41, 14 июня 2011 (UTC)

Как Вы оцениваете важность конкурентов? Почему Вы считаете, что VSS не входит в то самое большинство? Или Вы ограничиваетесь лишь бесплатными системами родом из Юникса? --Nashev 11:49, 15 июня 2011 (UTC)

Я знаю о проектах, которые переходят с SVN на распределённые системы. Если у вас есть данные (подтвержденные ссылками) о прямой конкуренции между SVN и VSS, то было бы даже интересно добавить это в статью. Тем не менее, сравнение с отдельными конкретными системами - не лучшая идея. Возможно, есть статья "Сравнение систем управления версиями". Если нет - напишите. --SergV 17:49, 15 июня 2011 (UTC)

Минимальное получение из хранилища

Рабочая копия — это созданная клиентской программой Subversion локальная копия части данных из хранилища, содержащая помимо собственно данных некоторую служебную информацию (скрытые директории с именем .svn). Служебная информация необходима для правильного функционирования рабочей копии; что-либо менять в служебных данных нельзя. Минимальной единицей данных, которую можно получить из хранилища как рабочую копию, является директория. Другими словами, в Subversion рабочая копия всегда соответствует ровно одной директории хранилища. Извлечь из хранилища отдельный файл как рабочую копию невозможно.

Во даном абзаце ничего не говорится о содержимом директории, и из него создаётся впечатление, что забрать директорию можно исключительно целиком, со всем её содержимым. Но с учётом того, что можно создавать рабочую копию нерекурсивно, да и есть ещё sparse directories, это впечатление является обманчивым. Как бы исправить/дополнить абзац, чтоб такого впечатления не создавалось? --Nashev 12:51, 14 июня 2011 (UTC)

Написать-то можно, но есть ли смысл? Неполный чекаут делается параметром --depth команды checkout. У каждой команды есть параметры, и если все это в статье расписывать, то она будет перегружена. Нельзя же всю документацию сюда впихнуть. --Кae 15:29, 14 июня 2011 (UTC)

А если так, как думаете, будет понятно?

Рабочая копия — это созданная клиентской программой Subversion локальная копия части данных из хранилища, содержащая помимо собственно данных некоторую служебную информацию (скрытые директории с именем .svn). Служебная информация необходима для правильного функционирования рабочей копии; что-либо менять в служебных данных нельзя. Минимальной единицей данных, которую можно получить из хранилища как рабочую копию, является директория (без её содержимого). Другими словами, в Subversion рабочая копия всегда соответствует ровно одной директории хранилища. Извлечь из хранилища отдельный файл как рабочую копию невозможно.

Я думаю, что такая формулировка только вводит в заблуждение. Как будто делаем чекаут и получаем директорию без содержимого. ИМХО это вообще можно не описывать. Я сначала сам хотел описать в статье всё-всё. Но увидел, что статья разрастается, и в ней появляется сто тыщ сносок и замечаний в скобочках. Теперь я думаю, что в статье должен быть только общий обзор. Статья ни в коем случае не есть замена документации. Кому нужны детальные данные по фичам - прочитают документацию по командам. --Кae 19:53, 14 июня 2011 (UTC)

А так? Не вдаваясь в подробности отдельных команд, описывая только идеологию с необычными её деталями. --Nashev 11:49, 15 июня 2011 (UTC)

Рабочая копия — это локальная директория со служебной информацией (скрытая поддиректория с именем .svn), сопоставленная с конкретной ветвью конкретного репозитория SVN. Создаётся клиентской программой Subversion. Служебная информация необходима для правильного функционирования рабочей копии; что-либо самостоятельно менять в служебных данных не рекомендуется. В зависимости от режима создания, может содержать (и, как правило, содержит) все пользовательские файлы из соответствующей директории репозитория и/или аналогичные рабочие копии всех дочерних директорий этой ветви. В служебной информации к рабочей копии, кроме прочего, хранятся базовые для неё ревизии содержащихся в ней пользовательских файлов, поэтому рабочая копия более чем в два раза превышает по объёму аналогичную директорию, не внесённую под версионный контроль SVN.

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

Если честно, то ваш текст очень трудно понять (особенно второй абзац). Кроме того, много неточностей. Я написал в статье упоминание про чекаут без поддиректорий, надеюсь, это как-то закроет вопрос. --Кae 15:17, 15 июня 2011 (UTC)

RTFM! Как вариант на великом и могучем: http://tortoisesvn.net/docs/release/TortoiseSVN_ru/tsvn-dug-checkout.html Даже если на нём tl;dr - читайте со слов "Для легкого выбора элементов ..."

Директория vs Каталог

Как кто относится к исправлению всех упоминаний в статье слова Директория на слово Каталог? Ведь первое — калька с английского, второе — массово признанный вариант перевода. --Nashev 12:23, 15 июня 2011 (UTC)

Я не против. Когда статья писалась, в википедии была статья директория (а каталог перенаправлен). Потом сменили на каталог — пусть будет каталог. --Кae 14:38, 15 июня 2011 (UTC)

А второе - калька с французского. В живой речи я Каталог не встречал уже несколько лет. Вообще в данном случае лично я считаю придуманные Майкрсофтом термины "папка"/"folder" очень удачными. 85.90.120.180 12:46, 5 июля 2012 (UTC)

хорошая статья?

она же огромная 91.205.48.50 14:27, 10 октября 2012 (UTC)OMGWhatAStupidNickName