SVN: Игнорирование уже зафиксированного файла

Ответ 1

Сделайте чистую проверку, svn delete файл и добавьте игнорирование. Затем зафиксируйте это. Всем остальным придется позаботиться (один раз), что их локальная копия не будет удалена в следующем svn update, но после этого локальный файл останется без изменений и проигнорирован SVN.

Ответ 2

Если вы удалите файл из контроля версий, как разработчик, новый для проекта (или тот, кто случайно удалил свою локальную копию), получит его после первоначальной проверки? Что делать, если есть дополнения к файлу настроек?

Я бы предложил следующее: сохранить файл настроек по умолчанию (без паролей, имен хостов, строк подключения и т.д.) в SVN, назовите его что-то вроде settings.dist, и пусть код работает с копией этого имени settings. Каждый разработчик должен сделать эту копию один раз и затем может работать с ее персонализированными настройками. Если есть дополнения, добавьте их в settings.dist - все остальные получат их с обновлением и могут слиться в свою персонализированную копию.

Ответ 3

После удаления файла ваши пользователи должны будут восстановить файл из репозитория с помощью svn export.

$ svn export -r x path ./

Где x - это версия, где файл существовал до его удаления, path - это полный путь к файлу, а ./ - это место, где будет помещен файл.

Подробнее см. svn help export.

Ответ 4

У меня подобная проблема. В моем случае это автоматический файл настроек пользователя (visual studio), который был случайно проверен в самом начале проекта. Хотя просто удаление этого может работать, кажется, что correct удалить его из истории, поскольку он никогда не должен был быть там, в первую очередь.

Я столкнулся с этим, что может быть новой функцией, поскольку этот вопрос был первоначально отправлен 7.5 лет назад:

fooobar.com/questions/162413/...

Кажется, идея была бы такой:

1) create a dump of the project.
2) filter the dump using `svndumpfilter` to exclude the unwanted file(s).
3) load the dump as a new project.

Это может быть единственный способ полностью избавиться от файла. В большинстве случаев подход "удалить и игнорировать" может быть достаточно хорошим.

Ответ 5

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

В мире с Ant, у вас будут файлы:

settings.properties
settings-local.properties (ignored for Subversion)

и в вашем build.xml файле

<property file="settings-local.properties"/>
<property file="settings.properties"/>

Для тех, кто не смог соединить точки:

• изменить файл build.xml, например, предлагаемый
• установите параметр settings-local.properties как игнорируемый
• в init цели вашей сборки, скопируйте settings.properties в settings-local.properties
• Подождите пару дней, пока у всех не будет возможности запустить эту цель.
• удалить параметры settings.properties из Subversion

Voila, у каждого разработчика есть свои параметры setting-local.properties, и все было сделано автоматически (и ни один разработчик не потерял свои настройки, что происходит, если вы жестоко удалите файл из Suvbersion, и нет "Все остальные должны будут заботиться..." )

Ответ 6

[[Я новичок в подрывной деятельности, так что, возможно, это не имеет смысла. отметив это как wiki - если вы знаете правильный ответ, пожалуйста, ПРИЛОЖИТЕ в следующем разделе]]

У вас не будет настраиваемого набора шагов проверки, чтобы каждый пользователь получал другую папку настроек?

$ svn checkout http://example.com/project  project
..
$ dir project
original_settings\     folder1\     folder2\ 
$ svn checkout http://example.com/project/aaron_settings project\settings
..
$ dir project
original_settings\     folder1\     folder2\    settings\

Или для новых пользователей

$ svn import project\settings  http://example.com/project/aaron_settings

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

Это работает в подрывной деятельности? Вышеприведенный код выглядит очень рискованным, но, возможно, я делаю это неправильно.

WIKI:

(еще ничего)