Как избежать проверки локальных изменений в репозитории SVN?

Question

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

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

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

Попытался настроить мой второй репозиторий и просто проверить эти файлы в новом репозитории. Это стало очень грязно и в основном не сработало.

Я рассматриваю SVK - похоже, он МОЖЕТ помочь, но я не могу понять, какой шаблон будет работать.

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

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

Любые предложения о том, как это сделать?

Answer 1

Каким клиентом вы пользуетесь?

TortoiseSVN имеет изящную функцию, которая использует функцию changelist , встроенную в SVN. Если вы щелкнете правой кнопкой мыши по измененной папке и выберите «Проверить наличие изменений», вы можете щелкнуть правой кнопкой мыши любой из измененных файлов в этом диалоговом окне и выбрать «Добавить в список изменений -> игнорировать при фиксации». С тех пор, когда вы выполняете коммит, Tortoise старается не добавлять эти файлы в коммит. См. «Исключение элементов из списка фиксации» на этой странице .

Если вы не используете черепаху, вы можете настроить подобный список изменений вручную.

Answer 2

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

Answer 3

Я обычно пытаюсь упорядочить вещи так, чтобы стандартные файлы, проверенные SVN, могли быть переопределены отдельным файлом, который называется svn: ignore-ed

Например, у меня есть скрипт bash, который запускает веб-сервер Jetty с помощью файла конфигурации. Обычно это jetty.xml, но если в файловой системе присутствует jetty-local.xml, он используется вместо этого.

(Конечно, очевидная проблема состоит в том, что когда jetty.xml получает некоторые обновления, они не будут объединены в jetty-local.xml, но это может быть меньшей проблемой, чем то, с чем вы уже столкнулись. )

В проекте PHP, над которым я работал, это было продвинуто еще дальше с двумя отдельными деревьями кода - / system, в которой были извлечены все системные классы, и / local, который отражал его, но был пуст, если только локальный класс не был добавлено, в этом случае он был загружен в настройках. Это может стать слишком причудливым для его же блага.

Если проблема связана с файлами конфигурации, которыми вы владеете, другое решение, которое я использовал, - это организовать их иерархическое чтение (т. Е. Чтение в global.cfg.default, а затем перезаписать любые параметры в global.cfg.local) .

Answer 4

Когда я сталкиваюсь с подобной ситуацией, я добавляю файлы, которые я не хочу регистрировать, в набор изменений, помеченный как «НЕ ПРОВЕРЯТЬ». Мой SVN-клиент ( SmartSVN , хотя Tortoise и это поддерживает) может затем быть настроен на игнорирование этого набора изменений, что означает, что я случайно не проверяю эти изменения.

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

Answer 5

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

Если вы работаете на машине с Unix / Linux с установленным tksvn w / tkdiff, вы можете проверить хорошее графическое представление каждого diff по одному с помощью этой команды:

for FILE in `svn status | grep -v ? | sed -n "s/^[MA]//p"`; do tkdiff $FILE; done

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

Answer 6

Решение зависит от того, сколько изменений вы говорите. Я работаю с сайтами .net, поэтому для большинства сайтов у меня будет свой конфигурационный файл для каждой среды. например:

web.deploy.config
web.dev.config

Все это будет под контролем источника. Затем скопируйте один из этих файлов в файл web.config на сервере, на котором он работает (оставив этот файл вне контроля исходного кода). У меня работает.

Answer 7

Мне повезло, используя svn switch, чтобы не допустить перетекания персонализированных файлов в конфигурации других пользователей. При нормальной компоновке ствола / веток / тегов создайте себе папку в ветвях, содержащую ваш персонализированный файл конфигурации. Тогда

svn switch URL-to-personalized-config URL-to-standard-config

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

Answer 8

Я не могу придумать ни одного простого способа сделать это. Нет ли способа динамически проверить (в ваших файлах / сценариях), в какой среде вы находитесь, и соответственно настроить параметры? Раньше я делал это в PHP с простой проверкой каталогов (если рабочий каталог равен C: \ projects ..., тогда задайте путь к ...)

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