Как избежать проверки локальных изменений в репозитории SVN?
Я должен внести локальные изменения в файлы моего проекта, чтобы он работал в другой среде. Дважды я случайно проверил эти изменения (и испортил все остальные).
Вероятно, есть много лучших способов настроить нашу сборку, но, поскольку я работаю консультантом в уже существующем проекте, я не могу изменить то, как работает клиент.
Я попытался настроить вторую ветвь в том же репозитории (которая привела к обратному результату, дублируя все дерево в корне их репозитория - я не буду снова возиться с этим).
Попытался настроить мой второй репозиторий и просто проверить эти файлы в новом репозитории. Это стало действительно грязно и в основном не сработало.
Я рассматриваю SVK- похоже, он МОЖЕТ помочь, но я не могу понять, какая модель будет работать.
Я думаю, что я даже написал здесь и не получил хорошего ответа, но это было до того, как я серьезно задумался о SVK- я подумал, что с этим новым параметром может быть лучшее решение.
Я понимаю, что могу отследить изменения, которые я ХОЧУ, чтобы зарегистрировать, а затем просто зарегистрировать их, но это зависимая от человека и ошибочная процедура, которая на сегодняшний день меня дважды подводила (потому что я человек с ошибками).
Любые предложения о том, как это сделать?
8 ответов
Каким клиентом вы пользуетесь?
TortoiseSVN имеет изящную функцию, которая использует функцию списка изменений, встроенную в SVN. Если вы щелкнете правой кнопкой мыши по измененной папке и выберете "Проверить наличие изменений", вы можете щелкнуть правой кнопкой мыши по любому из измененных файлов в этом диалоговом окне и выбрать "Добавить в список изменений -> игнорировать при фиксации". С тех пор всякий раз, когда вы выполняете коммит, Tortoise старается не добавлять эти файлы в коммит. См. "Исключение элементов из списка фиксации" на этой странице.
Если вы не используете черепаху, вы можете настроить подобный список изменений вручную.
Вы можете использовать git-svn. Вы получаете локальное репо, в котором вы можете иметь локальную историю, и несколько возможностей рассмотреть ваши грехи, прежде чем навязывать их в репозиторий svn.
Я обычно стараюсь все устроить так, чтобы стандартные файлы, проверенные 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).
Когда я сталкиваюсь с подобной ситуацией, я добавляю файлы, которые я не хочу регистрировать, в набор изменений, помеченный как "НЕ ПРОВЕРИТЬ". Мой SVN-клиент ( SmartSVN, хотя Tortoise и делает это) также может быть настроен на игнорирование этого набора изменений, что означает, что я не случайно проверяю эти изменения.
Единственным недостатком этого является то, что вы внесли изменения в файлы в наборе изменений, который вы действительно хотите зарегистрировать - тогда вам придется вручную не забывать их регистрировать.
Я всегда проверяю различия всех своих файлов перед фиксацией, таким образом я могу убедиться, что я не оставляю некоторый отладочный код, и это дает мне второй шанс просмотреть мои изменения.
Если вы работаете на машине с Unix/Linux с установленным tksvn w/ tkdiff, вы можете проверить хорошее графическое представление каждого diff по одному с помощью этой команды:
for FILE in `svn status | grep -v ? | sed -n "s/^[MA]//p"`; do tkdiff $FILE; done
Еще один разумный способ проверить себя заново - проверить свежую копию репозитория и попытаться создать и запустить ее - таким образом вы можете поймать, если вы забыли добавить файл или сломали что-то очевидное.
Решение зависит от того, сколько изменений вы говорите. Я работаю с сайтами.net, поэтому для большинства сайтов у меня будет свой конфигурационный файл для каждой среды. например:
web.deploy.config
web.dev.config
Все это будет под контролем источника. Затем скопируйте один из этих файлов в файл web.config на сервере, на котором он запущен (оставив этот файл вне контроля исходного кода). Работает для меня.
Мне повезло с помощью svn switch чтобы не допустить перетекания персонализированных файлов в конфигурации других пользователей. При нормальной компоновке ствола / веток / тегов создайте себе папку в ветвях, содержащую ваш персонализированный файл конфигурации. затем
svn switch URL-to-personalized-config URL-to-standard-config
Это приведет к тому, что изменения в файле конфигурации будут сохранены в вашей ветке, а не в стволе. Вы получаете версионные правки в ваш конфигурационный файл, и не можете легко испортить ствольный файл.
Я не могу придумать ни одного простого способа сделать это. Нет ли способа динамически проверить (в ваших файлах / сценариях), в какой среде вы находитесь, и соответственно настроить параметры? Раньше я делал это в PHP с простой проверкой каталогов (если рабочий каталог равен C:\projects..., тогда установите путь к...)
Другим вариантом может быть ловушка перед фиксацией, которая исключает или возвращает измененные файлы, но в первом случае вы не будете в курсе, а во втором вам придется вносить изменения снова... хммм.