Svn как удалить файл
может ли кто-нибудь предложить мне, как удалить полный проект SVN из репозитория SVN (репозиторий svn находится в linux). Я нашел "svn delete", но не думаю, что он делает то же самое. Это помогает только в удалении файлов или подпапок, но не всего проекта.
этот ответ может ввести в заблуждение
читать комментарии к этой статье, и убедитесь, что это то, что вы после
'svn delete' работает против содержимого репозитория, а не против самого репозитория. для обслуживания репозитория (например, полного удаления) вы должны использовать svnadmin. Однако есть причина, по которой у svnadmin нет подкоманды "delete". Вы можете просто
где $REPOS_PATH-это путь, который вы использовали для создания своего репозитория с помощью
для этого требуется доступ к репозиторию svn на стороне сервера, поэтому у вас должны быть некоторые права администратора.
он работает путем (a) сброса содержимого репозитория в файл, (b) исключения некоторого содержимого и (c) очистки и повторного создания простого репозитория и в конечном итоге (d) загрузив содержимое отфильтрованного репозитория:
счетчик репозитория не изменяется в результате этих операций. Однако теперь в вашем репозитории "отсутствуют" все номера ревизий, используемые для создания содержимого, которое вы удалили на шаге (b).
Subversion 1.7.5, похоже, очень хорошо справляется с этими "отсутствующими" ревизиями. Используя "svn ls-r $missing", например, сообщает то же самое, что и "svn ls - r $(( missing-1))".
вопреки этому, моя (довольно старый) VIEWVC сообщает " нет содержимого "при запросе" отсутствующей " ревизии.
в случае, если вы просто хотите удалить проект из редакции head, чтобы он больше не отображался в вашем РЕПО при запуске svn list file:///path/to/repo/ просто запустите:
однако, если вам нужно удалить всю запись в репо, используйте другой метод.
я тоже чувствовал, что принятый ответ немного вводит в заблуждение, поскольку он может привести к тому, что пользователь непреднамеренно удалит несколько проектов. Неточно утверждать, что слова репозиторий, проект и каталог неоднозначны в контексте SVN. У них есть определенные значения, даже если сама система не навязывает эти значения. Сообщество и, что более важно, клиенты SVN имеют согласованное понимание этих условий, которые позволяют им помечать, ветвить и объединять.
в идеале это поможет устранить любую путаницу. Как кто-то, кто должен был перейти от git к svn для нескольких проектов, это может быть неприятно, пока вы не узнаете, что ветвление SVN и проекты SVN действительно говорят о структурах папок.
SVN терминология
хранилище
база данных фиксирует и истории для ваших папок и файлов. Репозиторий может содержать несколько "проектов" или нет проекты.
проект
определенная структура папок SVN, которая позволяет инструментам SVN выполнять тегирование, слияние и ветвление. SVN по своей сути не поддерживает ветвление. Ветвление было добавлено позже и является результатом специальной структуры папок следующим образом:
- /проекта
- / tags
- /филиалы
- /багажник
Примечание.: Помните, что SVN "проект" - это термин, используемый для определения конкретной папки strcuture в репозитории
проекты в репозитории
Макет Репозитория
- / "вонючка" "Project" due to layout
- / tags
- /филиалы
- /багажник
- / tags
- /филиалы
- /багажник
- / tags
- /филиалы
- /багажник
- / subdir
- /приложении app2 "Project" due to layout
- / tags
- /филиалы
- /багажник
поскольку репозиторий-это всего лишь база данных файлов и фиксаций каталогов, он может размещать несколько проектов. При обсуждении репозитории и проекты убедитесь, что используется правильный термин.
удаление хранилище может означать удаление нескольких проекты!
локальный каталог SVN (.каталог svn в корневом каталоге)
при использовании url фиксации происходят автоматически.
удалить a Проект: svn rm skunkworks + svn commit
потому что SVN проект это действительно определенная структура каталогов, удаление проекта-это то же самое, что удаление каталога.
управление репозиторием SVN
есть несколько SVN серверы, доступные для размещения репозиториев. Управление самими репозиториями обычно осуществляется через консоли администрирования серверов. Например, Visual SVN позволяет создавать репозитории (базы данных), каталоги и проекты. Но вы не можете удалять файлы, управлять фиксациями, переименовывать папки и т. д. из консоли сервера, поскольку это конкретные задачи SVN. Сервер SVN обычно управляет созданием репозитория. После создания репозитория и у вас есть новый URL, остальная часть вашей работы выполняется через .
в svn нет понятия "проект". Итак, не стесняйтесь удалять все, что вы think принадлежит проекту.
удаление рабочей копии
Subversion не отслеживает ни состояние, ни существование рабочих копий на сервере, поэтому нет никаких накладных расходов сервера для хранения рабочих копий. Аналогичным образом, нет необходимости сообщать серверу, что вы собираетесь удалить рабочую копию.
Если вы, скорее всего, снова используете рабочую копию, нет ничего плохого в том, чтобы просто оставить ее на диске, пока вы не будете готовы использовать ее снова, и в этот момент все это займет это обновление svn, чтобы обновить его и подготовить к использованию.
однако, если вы определенно не собираетесь снова использовать рабочую копию, вы можете безопасно удалить все это, используя любые возможности удаления каталогов, которые предлагает ваша операционная система. мы рекомендуем перед этим запустить svn status и просмотреть все файлы, перечисленные в его выходных данных, которые имеют префикс a ? чтобы убедиться, что они не важны.
легко поверить, что удаление всего репозитория Subversion требует "информирования" Subversion о том, что вы собираетесь удалить репозиторий. Но Subversion заботится только об управлении репозиторием после его создания, а не о том, существует ли репозиторий или нет ( если это имеет смысл ). Это происходит следующим образом: инструменты и команды Subversion не страдают от простого удаления каталога репозитория с помощью обычных утилит операционной системы (например, rm-R). Каталог репозитория это не то же самое, что установленный каталог программы, где удаление программы без удаления может оставить после себя неустойчивые файлы конфигурации или другие зависимости. Репозиторий на 100% самодостаточен в своем каталоге, и его удаление безвредно (кроме потери истории проекта). Вы просто очищаете сланец, чтобы создать новый репозиторий Subversion и импортировать свой следующий проект.
идем в Eclipse, Нажмите на окно в строке меню, затем "открыть перспективу - > другое - > SVN Repository Exploring -> нажмите OK"
теперь, после выполнения "нажмите OK", вам нужно перейти на грузовик (или место, где ваш проект сохраняется в SVN), затем выберите проект(который вы хотите удалить), затем щелкните правой кнопкой мыши -> удалить.
это удалит проект из subversion.
правильное предложение: svnadmin deltify $PATH. не forghet для удаления проекта или репозитория из файла svn-acl (если вы его используете). если вы просто удалите папку репозитория, вы можете повредить каталог svn в зависимости от того, как ваш svn настроен в вашей среде.
Subversion позволяет переименовывать и перемещать файлы и папки. Так есть пункты меню для удаления и переименования в подменю TortoiseSVN.
Рисунок 4.34. Контекстное меню Проводника для версированных файлов
Удаление файлов и папок
Для удаления файлов и папок из Subversion применяется команда TortoiseSVN → Удалить .
Когда вы решаете TortoiseSVN → Удалить файл или папку, они сразу же удаляются из вашей рабочей копии и помечаются для удаления в хранилище при следующей фиксации. Родительская папка этого элемента отображается с пометкой « изменённый » . До тех пор, пока не произведена фиксация, вы можете вернуть файл обратно, если вызовете TortoiseSVN → Убрать изменения на родительской папке.
Если вы желаете удалить какой-нибудь объект из хранилища, но в то же время оставить его локально как неверсированный файл/папку, воспользуйтесь Расширенное контекстное меню → Удалить (оставив локально) . Вам необходимо удерживать клавишу Shift при правом щелчке на объекте в панели со списком файлов Проводника (правая панель) для того, чтобы увидеть этот пункт в расширенном контекстном меню.
Если элемент удаляется в Проводнике, а не при помощи контекстного меню TortoiseSVN, диалог фиксации отобразит такие элементы и позволит вам удалить их также из под управления версиями перед фиксацией. Однако, если вы обновите вашу рабочую копию, Subversion обнаружит отсутствующий элемент и заменит его последней версией из хранилища. Если вам необходимо удалить файл, находящийся под управлением версиями, всегда используйте TortoiseSVN → Удалить , чтобы Subversion не приходилось угадывать, что вы хотите сделать на самом деле.
Возвращение назад удалённого файла или папки
Если вы удалили файл или папку и уже зафиксировали эту операцию удаления в хранилище, то обычное TortoiseSVN → Убрать изменения не вернет это назад. Но файл или папка не потеряны навсегда. Если вы знаете ревизию в которой был удален файл или папка (если не знаете — найдите в журнале), то откройте обозреватель хранилища и переключитесь на эту ревизию. Затем выберите удаленный файл или папку, нажмите правую кнопку мыши и выберите Context Menu → Копировать в.
Перемещение файлов и папок
Если вы желаете просто переименовать (без перемещения) файл или папку , используйте Контекстное меню → Переименовать. Введите новое имя переименуемого объекта и это всё.
Если вы хотите переместить файлы внутри вашей рабочей копии, возможно в другую подпапку, воспользуйтесь обработчиком перетагивания правой кнопкой мыши:
выберите файлы или папки, которые вы желаете переместить
затем перетащите правой кнопкой мыши их на новое место внутри рабочей копии
отпустите правую кнопку мыши
в появившемся меню выберите Контекстное меню → SVN Переместить версированные файлы сюда
Фиксируйте родительскую папку
Поскольку переименование и перемещение выполняются как удаление с последующим добавлением, вам необходимо выполнить фиксацию родительской папки перемещённого/удалённого файла, так чтобы удаляемая часть переименования/перемещения отображалась в диалоге фиксации. Если вы не зафиксируете удаляемую часть переименования/перемещения, она останется в хранилище и у тех, кто работает вместе с вами, при обновлении старые файлы удалены не будут, т.е. у них окажутся обе копии: и старая, и новая.
Вы должны зафиксировать переименование папки перед изменением любого файла внутри этой папки, иначе ваша рабочая копия может реально прийти в беспорядок.
Другим способом перемещения или копирования файлов является использования команд Windows копировать/вырезать. Выберите файлы, которые вы хотите скопировать, сделайте правый клик и выберите Context Menu → Копировать в контекстном меню проводника. Затем перейдите в целевую папку, сделайте правый клик и выберите TortoiseSVN → Вставить . Для перемещения файлов выберите Context Menu → Вырезать вместо Context Menu → Копировать .
Можно использовать также обозреватель хранилища для перемещения файлов и папок. Чтобы узнать больше о том, как это сделать, прочтите «Обозреватель хранилища».
Не перемещайте внешнее при помощи SVN
Не надо применять команды TortoiseSVN Переместить или Переименовать к папкам, созданным с использованием svn:externals . Это действие приводит к удалению внешних элементов из их родительского хранилища, вероятно вызывая замешательство у множества других людей. Если вам необходимо переместить папку с внешним, то надо использовать обычное перемещение в оболочке (например, Проводнике), а затем настроить свойство svn:externals исходной и целевой родительских папок.
В случае, когда у вас в хранилище есть два файла с одинаковыми именами, различающиеся только регистром (например, TEST.TXT и test.txt ), вы больше не сможете обновить или извлечь папку, содержащую эти файлы, при помощи клиента под Windows. Хотя Subversion и поддерживает имена файлов, различающиеся регистром, их не поддерживает Windows.
Иногда это случается, когда два человека фиксируют из двух различных рабочих копий файлы, имеющие одинаковые имена, но отличающиеся регистром символов. Это также может случиться при фиксации файлов из ОС, файловая система которой учитывает регистр, такой как Linux.
В этом случае вам необходимо решить, какой из них вы желаете сохранить и удалить (или переименовать) другой из хранилища.
Предотвращение двух одинаковых имён у файлов
Исправление переименования файлов
Иногда ваша дружественная IDE переименовывает для вас файлы в процессе осуществления рефакторинга, и, конечно же, не сообщает об этом Subversion. При попытке зафиксировать изменения, Subversion будет видеть файл со старым именем как отсутствующий, а с новым - как неверсированный. Конечно, вы можете пометить новое имя для того, чтобы оно было добавлено, но тогда будет потеряна история изменений, поскольку Subversion не знает о взаимосвязи двух этих файлов.
Удаление неверсированных файлов
Обычно ваш список игнорирования настроен так, чтобы Subversion игнорировала все генерируемые файлы. Но что, если вы желаете очистить все эти игнорируемые элементы для порождения чистой сборки? Как правило, вы настраиваете это в вашем сборочном файле, но если вы отлаживаете сборочный файл, или изменяете систему сборки, полезно иметь способ очистки места действия.
TortoiseSVN предоставляет именно такую возможность, применяя Расширенное контекстное меню → Удалить неверсированные элементы. . Вам необходимо удерживать клавишу Shift при правом щелчке на папке в панели со списком Проводника (правой панели) для того, чтобы увидеть этот пункт в расширенном контекстном меню. Это выводит диалог, в котором будут перечислены все неверсированные файлы со всей вашей рабочей копии, и вы сможете отметить или разотметить элементы для удаления.
При удалении такого рода элементов используется корзина, поэтому, если вы совершили ошибку и удалили файл, который должен быть версирован, вы всё ещё можете получить его обратно.
Команда svn delete (svn rm), насколько я понял по руководству по SVN, подготавливает файл к удалению, а затем при up-е обязательно удаляет так же файл из рабочей копии.
Можно ли сделать так, чтобы SVN просто начал игнорировать конкретные файлы? (удалил их из репозитория, но не затрагивал их при этом в рабочих копиях)
Удалить файл из репозитория, но оставить в файловой системе: svn rm filename --keep-local
- Сделать файл list с именами или масками, разделённые переводом строки
- Выполнить svn propset 'svn:ignore' -F list .
- list можно удалить.
Анатолий, откуда вы узнали про --keep-local?! В мануале я нигде такой опции не нашёл.
В результате эксперимента с опцией --keep-local выяснилось, что она всё-таки сохраняет файл в текущей рабочей копии, но всё равно удалит его в других при выполнении svn up. То есть это не всё равно не то.
Откуда узнал: svn help rm
Из других удаляет? Хмм, тогда мне самому теперь интересно, как бы осуществить такое удаление, и возможно ли вообще.
Забавно про svn help . ) Значит, об --keep-local ещё не успели написать в мануал.
Вот именно, что опция сейчас получается неполноценной. А так ей бы цены не было!
Нет, речь совсем не об этом. Нужно именно удалить файл (файлы) из-под версионного контроля, а не просто начать игнорировать его в конкретной рабочей копии.
svn propedit svn:ignore log
открывается редактор и мы можем задавать маски игнорирования
* - игнорит все
*.log - игнорит по маске только .logвсе установки игнорирования действуют только на новые файлы… даже если файлы небыли добавлены в SVN но существовали SVN будет на них ругаться что они не под контролем, их надо переместить сделать коммит и вернуть
«даже если файлы небыли добавлены в SVN» — были, были добавлены. Можете считать, что по ошибке. Речь не об игнорировании, речь о всего лишь удалении из-под версионного контроля.
anatoly_rr предложил замечательную опцию --keep-local, но она работает только один раз. При обновлении других рабочих копий эта опция уже игнорируется (т. к. видимо SVN не предусматривает того, что файл можно удалить из репозитория, но оставить его в рабочих копиях). Неужели такого нет?
Так почему бы не сделать так. Переместить файл, svn покажет что его нет, делаем svn rm он удаляет его из репо, коммит, затем ставим файл на место, SVN показывает что файл новый с вопросиком (в консоли), далее ставим на файл игнор, коммит, и SVN его не трогает больше, он остается локально
Потому что этот файл удалится в остальных рабочих копиях при апдейте, если я правильно понял автора. Т.е. если какой-то файл типа settings.conf , который, скажем, у всех разработчиков разный, был случайно добавлен в репозиторий, то чтобы его оттуда удалить, танцы с перемещениями придётся исполнять всем разработчикам для своих рабочих копий.
Именно — танцы. Я вовсе не говорю, что решения нет. Я о том, что мы можем решить эту задачу сейчас именно посредством только таких танцев, а не какими-то более штатными средствами.
Вы уже читали о рабочих копиях, сейчас мы покажем, как клиент Subversion их создаёт и использует.
Рабочая копия Subversion - это обычное дерево папок в вашей локальной системе, содержащее набор файлов. Вы можете изменять эти файлы по своему усмотрению, и, если это исходные коды, вы можете скомпилировать программу из них обычным способом. Ваша рабочая копия - это ваша собственная личная рабочая область: Subversion никогда не вносит изменения, сделанные другими, также как и не передаёт другим изменения, сделанные вами, до тех пор, пока вы сами явно не скажете ей сделать это.
После того, как вы произвели некоторые изменения в файлах вашей рабочей копии и убедились, что они работают правильно, вы можете воспользоваться представленными в Subversion командами для публикации ваших изменений, чтобы сделать их доступными другим людям, работающим вместе с вами над проектом (путём записи в хранилище). Когда другие люди публикуют свои изменения, Subversion предоставляет вам команды для слияния этих изменений с файлами в вашей рабочей папке (путём чтения из хранилища).
Рабочая копия содержит несколько дополнительных файлов, созданных и поддерживаемых клиентом Subversion, чтобы помочь ему в работе. Например, ваша рабочая копия содержит подпапку .svn - административную папку рабочей копии. Файлы в этой папке помогают svn-клиенту распознать, какие файлы содержат неопубликованные изменения, а какие устарели. До версии 1.7 Subversion создавал административные папки .svn в каждой подпапке вашей рабочей копии. Subversion 1.7 использует совершенно другой подход. Теперь каждая рабочая копия содержит только одну административную папку в корне рабочей директории.
Типичное хранилище Subversion часто содержит файлы (или исходный код) нескольких проектов, обычно каждый проект - это подпапка в дереве файловой системы хранилища. При таком подходе, пользовательская рабочая копия будет соответствовать какому-то поддереву в хранилище.
Например, предположим, что у вас есть хранилище с двумя программными проектами.
Рисунок 2.6. Файловая система хранилища
Другими словами, корневая папка хранилища содержит две папки: paint и calc .
Для получения рабочей копии, вы должны извлечь некоторое поддерево хранилища. (Термин извлечение (check out) по-английски может звучать как что-то, связанное с блокированием или резервированием ресурсов, но это не так: оно просто создаёт для вас личную копию проекта).
Предположим, вы вносите изменения в button.c . Так как в папке .svn запоминается дата модификации файла и исходное содержимое, Subversion может узнать, что вы изменили файл. Однако, Subversion не делает ваши изменения доступными другим, пока вы явно не скажете ей об этом. Действие по опубликованию ваших изменений, обычно известно как фиксация (или внесение) изменений в хранилище.
Для обнародования ваших изменений, вы должны использовать команду Subversion фиксировать (commit) .
Теперь ваши изменения в button.c были зафиксированы в хранилище; если другой пользователь извлечёт рабочую копию /calc , он увидит ваши изменения в последней версии файла.
Предположим, вы работаете вместе с Салли, которая извлекла рабочую копию /calc в то же время, что и вы. Когда вы фиксируете ваши изменения в button.c , рабочая копия Салли остаётся неизменной, Subversion изменяет рабочие копии только по запросу пользователя.
Для приведения своего проекта в актуальное состояние, Салли может попросить Subversion обновить её рабочую копию, используя команду обновить (update) . В результате, в её рабочую копию будут внесены как ваши изменения, так и изменения других, зафиксированные с момента извлечения Салли своей рабочей копии.
Обратите внимание, Салли не надо указывать, какие файлы обновлять, Subversion использует информацию в папке .svn , а затем информацию из хранилища, для определения того, какие файлы нуждаются в обновлении.
Адреса URL хранилища
Хранилища Subversion могут быть доступны посредством множества различных методов - с локального диска или через различные сетевые протоколы. Описание расположения хранилища, однако, всегда является разновидностью URL. Схема URL показывает метод доступа:
Таблица 2.1. URL для доступа к хранилищу
В большинстве случаев, для URL в Subversion используется стандартный синтаксис, позволяющий указывать имя сервера и номер порта в URL. Метод доступа file:// обычно используется для локального доступа, хотя он может быть использован с путями UNC для доступа к узлам по сети. В этом случае URL имеет форму file://имя-компьютера/путь/к/хранилищу . Для локальной машины часть имя-компьютера должна быть либо пропущена, либо указана как localhost . По этой причине, локальные пути обычно указывают с тремя косыми чертами (/), file:///путь/к/хранилищу .
Также, пользователи схемы file:// на платформе Windows вынуждены использовать неофициальный « стандарт » синтаксиса для доступа к хранилищам, находящимся на той же машине, но на дисках, отличных от текущего рабочего диска пользователя. Будет работать любой из двух приведённых ниже синтаксиса путей URL ( X обозначает диск, на котором находится хранилище):
Обратите внимание, в URL используется обычная (прямая) косая черта, хотя в исходной (не URL) форме путей в Windows используется обратная косая черта.
Вы можете получить доступ к хранилищу FSFS через сетевой ресурс, но это не рекомендовано по разным причинам:
Вы даете прямой доступ на запись всем пользователям, таким образом они могут случайно удалить или повредить файловую систему репозитория.
Не все протоколы для общего доступа к файлам по сети поддерживают блокировку, которую требует Subversion. Однажды вы обнаружите, что ваше хранилище слегка повреждено .
Вы должны настроить разрешения на доступ именно так, как нужно. SAMBA особенно сложен в этом отношении.
Если кто-то установит более свежую версию клиента, который обновит формат хранилища, то все остальные не смогут получить доступ к хранилищу пока также не обновят клиента до новой верии.
Ревизии
Команда svn commit может опубликовать изменения в любом количестве файлов и папок как одну атомарную транзакцию. В вашей рабочей копии вы можете изменить содержимое файла, создать, удалить, переименовать и скопировать файлы и папки, а затем зафиксировать весь набор изменений как единое целое.
Каждая фиксация в хранилище обрабатывается как атомарная транзакция: либо сохраняются все изменения, либо не сохраняется ни одно из них. Subversion старается поддерживать эту атомарность, несмотря на сбои программ, аварийные отказы систем, на сетевые проблемы и действия других пользователей.
Каждый раз при выполнении фиксации в хранилище создаётся новое состояние дерева файловой системы, называемое ревизией. Каждой ревизии назначается уникальный целочисленный номер, на единицу больший, чем у предыдущей ревизии. Начальная ревизия в только что созданном хранилище имеет номер ноль, и не содержит ничего, кроме пустой корневой папки.
Удачный способ мысленного представления хранилища - представить его в виде серии деревьев. Вообразите массив номеров ревизий, начинающийся с 0, и растущий слева направо. Под каждым номером ревизии расположено дерево файловой системы, и каждое дерево - это « снимок » состояния хранилища после каждой фиксации.
Рисунок 2.7. Хранилище
Общие номера ревизий
В отличие от многих других систем управления версиями, номера ревизий в Subversion относятся к деревьям целиком , а не к отдельным файлам. Каждый номер ревизии обозначает целое дерево - некоторое состояние хранилища после зафиксированного изменения. Иначе говоря, можно считать, что ревизия N представляет состояние файловой системы хранилища после выполнения N-ой фиксации. Когда пользователь Subversion говорит о "ревизии 5 foo.c ", это в действительности означает " foo.c , каким он был в ревизии 5". Обратите внимание -- ревизии N и M одного и того же файла, таким образом, могут не иметь отличий.
Важно помнить то, что рабочие копии не всегда соответствуют какой-то одной ревизии в хранилище; они могут содержать файлы из разных ревизий. Например, вы извлекли рабочую копию из хранилища, в котором самая последняя ревизия имеет номер 4:
На данный момент рабочая папка полностью соответствует ревизии 4 в хранилище. Допустим, что вы внесли изменения в button.c , и зафиксировали эти изменения. При отсутствии других фиксаций ваша фиксация создаст ревизию под номером 5, и теперь ваша рабочая копия выглядит следующим образом:
Предположим, что после этого Салли фиксирует изменения в integer.c , создавая ревизию 6. Если вы воспользуетесь svn update для приведения своей рабочей копии в актуальное состояние, то она станет выглядеть так:
Изменения, внесенные Салли в integer.c , будут отражены в вашей рабочей копии, также как и ваши изменения будут присутствовать в button.c . В этом примере текст Makefile в ревизиях 4, 5 и 6 идентичен, однако, Subversion всё равно присваивает файлу Makefile в вашей рабочей копии номер ревизии 6, чтобы показать, что файл в актуальном состоянии. Таким образом, после того как вы выполните полное обновление вашей рабочей копии, она будет соответствовать точно одной ревизии в хранилище.
Как рабочие копии отслеживают хранилище
В служебной папке .svn/ для каждого файла рабочей папки Subversion записывает информацию о двух важнейших свойствах:
на какой ревизии основан ваш рабочий файл (это называется рабочая ревизия файла), и
дату и время, когда локальная копия последний раз обновлялась из хранилища.
Основываясь на этой информации, и взаимодействуя с хранилищем, Subversion может сказать, в каком из следующих четырех состояний находится рабочий файл:
Файл не изменялся в рабочей папке, и в хранилище не фиксировались изменения этого файла со времени его рабочей ревизии. Команды фиксировать (commit) и обновить (update) ничего делать не будут.
Изменён локально и не устарел
Файл был изменён в рабочей папке, и в хранилище не фиксировались изменения этого файла со времени его базовой ревизии. Существующие локальные изменения не были зафиксированы в хранилище, поэтому команда фиксировать (commit) для файла преуспеет в опубликовании ваших изменений, а команда обновить (update) ничего делать не будет.
Не изменялся и устарел
Файл в рабочей папке не изменялся, но был изменён в хранилище. Со временем, файл должен быть обновлён для соответствия текущей публичной ревизии. Команда фиксировать (commit) ничего делать не будет, а команда обновить (update) внесёт последние изменения в вашу рабочую копию.
Изменён локально и устарел
Файл был изменён как в рабочей папке, так и в хранилище. Команда фиксировать (commit) потерпит неудачу с ошибкой устарел (out-of-date) . Файл необходимо сначала обновить; команда обновить (update) попытается объединить опубликованные изменения с локальными. Если Subversion не сможет выполнить объединение в приемлемой форме самостоятельно, то заботу о разрешении конфликта она оставит пользователю.
Subversion allows renaming and moving of files and folders. So there are menu entries for delete and rename in the TortoiseSVN submenu.
Figure 4.34. Explorer context menu for versioned files
Deleting files and folders
Use TortoiseSVN → Delete to remove files or folders from Subversion.
When you TortoiseSVN → Delete a file or folder, it is removed from your working copy immediately as well as being marked for deletion in the repository on next commit. The item's parent folder shows a “ modified ” icon overlay. Up until you commit the change, you can get the file back using TortoiseSVN → Revert on the parent folder.
If you want to delete an item from the repository, but keep it locally as an unversioned file/folder, use Extended Context Menu → Delete (keep local) . You have to hold the Shift key while right clicking on the item in the explorer list pane (right pane) in order to see this in the extended context menu.
If an item is deleted via the explorer instead of using the TortoiseSVN context menu, the commit dialog shows those items as missing and lets you remove them from version control too before the commit. However, if you update your working copy, Subversion will spot the missing item and replace it with the latest version from the repository. If you need to delete a version-controlled file, always use TortoiseSVN → Delete so that Subversion doesn't have to guess what you really want to do.
Getting a deleted file or folder back
If you have deleted a file or a folder and already committed that delete operation to the repository, then a normal TortoiseSVN → Revert can't bring it back anymore. But the file or folder is not lost at all. If you know the revision the file or folder got deleted (if you don't, use the log dialog to find out) open the repository browser and switch to that revision. Then select the file or folder you deleted, right click and select Context Menu → Copy to. as the target for that copy operation select the path to your working copy.
Moving files and folders
If you want to do a simple in-place rename of a file or folder, use Context Menu → Rename. Enter the new name for the item and you're done.
If you want to move files around inside your working copy, perhaps to a different sub-folder, use the right mouse drag-and-drop handler:
select the files or directories you want to move
right drag them to the new location inside the working copy
release the right mouse button
in the popup menu select Context Menu → SVN Move versioned files here
Commit the parent folder
Since renames and moves are done as a delete followed by an add you must commit the parent folder of the renamed/moved file so that the deleted part of the rename/move will show up in the commit dialog. If you don't commit the removed part of the rename/move, it will stay behind in the repository and when your co-workers update, the old file will not be removed. i.e. they will have both the old and the new copies.
You must commit a folder rename before changing any of the files inside the folder, otherwise your working copy can get really messed up.
Another way of moving or copying files is to use the Windows copy/cut commands. Select the files you want to copy, right click and choose Context Menu → Copy from the explorer context menu. Then browse to the target folder, right click and choose TortoiseSVN → Paste . For moving files, choose Context Menu → Cut instead of Context Menu → Copy .
You can also use the repository browser to move items around. Read the section called “The Repository Browser” to find out more.
Do Not SVN Move Externals
You should not use the TortoiseSVN Move or Rename commands on a folder which has been created using svn:externals . This action would cause the external item to be deleted from its parent repository, probably upsetting many other people. If you need to move an externals folder you should use an ordinary shell move, then adjust the svn:externals properties of the source and destination parent folders.
Dealing with filename case conflicts
If the repository already contains two files with the same name but differing only in case (e.g. TEST.TXT and test.txt ), you will not be able to update or checkout the parent directory on a Windows client. Whilst Subversion supports case-sensitive filenames, Windows does not.
This sometimes happens when two people commit, from separate working copies, files which happen to have the same name, but with a case difference. It can also happen when files are committed from a system with a case-sensitive file system, like Linux.
In that case, you have to decide which one of them you want to keep and delete (or rename) the other one from the repository.
Preventing two files with the same name
Repairing File Renames
Sometimes your friendly IDE will rename files for you as part of a refactoring exercise, and of course it doesn't tell Subversion. If you try to commit your changes, Subversion will see the old filename as missing and the new one as an unversioned file. You could just check the new filename to get it added in, but you would then lose the history tracing, as Subversion does not know the files are related.
A better way is to notify Subversion that this change is actually a rename, and you can do this within the Commit and Check for Modifications dialogs. Simply select both the old name (missing) and the new name (unversioned) and use Context Menu → Repair Move to pair the two files as a rename.
Deleting Unversioned Files
Usually you set your ignore list such that all generated files are ignored in Subversion. But what if you want to clear all those ignored items to produce a clean build? Usually you would set that in your makefile, but if you are debugging the makefile, or changing the build system it is useful to have a way of clearing the decks.
TortoiseSVN provides just such an option using Extended Context Menu → Delete unversioned items. . You have to hold the Shift while right clicking on a folder in the explorer list pane (right pane) in order to see this in the extended context menu. This will produce a dialog which lists all unversioned files anywhere in your working copy. You can then select or deselect items to be removed.
When such items are deleted, the recycle bin is used, so if you make a mistake here and delete a file that should have been versioned, you can still recover it.
Читайте также: