[SVN] Откатиться к предыдущей ревизии
TortoiseSVN -> right-click on file -> Show Log -> right-click нужную ревизию -> Revert to this revision (или Revert changes from this revision если файл менялся после кривого коммита и эти изменения хочется сохранить)
right-click on fileА если изменена была тысяча файлов?
Кроме того, не делает ли оно стандартный svn revert/svn up? У меня сильное подозрение, что такой revert в репозиторий не попадёт
>А если изменена была тысяча файлов?
кликаешь правой кнопкой не в один файл, а в папку, где твоя тысяча файлов лежит
кликаешь правой кнопкой не в один файл, а в папку, где твоя тысяча файлов лежит
TortoiseSVN -> Help -> How Do I... -> Roll back revisions in the repository
Вкратце - если тысяча файлов - то правой клавишей по папке где лежит эта тысяча файлов
Кроме того, не делает. Твое сильное подозрение всего лишь подозрение.
Вкратце - если тысяча файлов - то правой клавишей по папке где лежит эта тысяча файлов
Кроме того, не делает. Твое сильное подозрение всего лишь подозрение.
а что,у вас разработчики транками не пользуются, да?
что такое транк?
Вкратце - если тысяча файлов - то правой клавишей по папке где лежит эта тысяча файлоНу-ну.
Есть очень большое дерево. И где-то в этом дереве есть испорченные файлы - раскиданы по всему дереву, по совершенно разным местам. Всего испорченных файлов - тысяча.
Или там можно для корневого каталога сделать это "rollback to"? И история для неиспорченных файлов не поменяется после коммита?
ЗЫ: Уже решили проблему так, как я написал в первом посте, но всё равно интересует, есть ли цивильное решение.
Поясни-ка свою мысль
можно по корневому
ты вместо того чтоб глупые вопросы задавать пошел бы давно уже и заценил интерфейс соотв и поигрался бы
сразу бы все проблемы отпали
Единственная проблема в таком случае будет если у тебя есть коммит на 2000 файлов, в котором 1000 была испорчена. И эта тысяча валяется по разным местам вместе с неиспорченной тысячей.
Но в таком случае ручного отсеивания испорченного от неиспорченного никак не избежать.
Да и твой способ вполне себе способ. Единственное, там можно было делать не чекаут, а экспорт, тогда .svn не пришлось бы вычищать.
ты вместо того чтоб глупые вопросы задавать пошел бы давно уже и заценил интерфейс соотв и поигрался бы
сразу бы все проблемы отпали
Единственная проблема в таком случае будет если у тебя есть коммит на 2000 файлов, в котором 1000 была испорчена. И эта тысяча валяется по разным местам вместе с неиспорченной тысячей.
Но в таком случае ручного отсеивания испорченного от неиспорченного никак не избежать.
Да и твой способ вполне себе способ. Единственное, там можно было делать не чекаут, а экспорт, тогда .svn не пришлось бы вычищать.
trunk, branch etc.
сильно облегчает жизнь в таких случаях имхо
сильно облегчает жизнь в таких случаях имхо
В случаях, когда уже поздно?
Как вариант,
svn rm <filename>
svn cp -r xx <filename>
svn commit
для всех изменившихся файлов. Скриптом (пенартур - .bat-файлом ).
Немного сложнее, чем метод с merge, зато кривой комит исчезнет из истории, и не загадит svn annotate.
svn rm <filename>
svn cp -r xx <filename>
svn commit
для всех изменившихся файлов. Скриптом (пенартур - .bat-файлом
).Немного сложнее, чем метод с merge, зато кривой комит исчезнет из истории, и не загадит svn annotate.
зато кривой комит исчезнет из историиКуда исчезнет?
для всех изменившихся файловНу-ну.
А когда изменилась/удалилась/добавилась неебическая куча файлов?
Метод с merge рулит.
Куда исчезнет?Неважно. Исчезнет.
На самом деле, конечно, останется, но изменения в файлах не отразятся.
Неужели ты не используешь svn annotate ?
Ну-ну.
А когда изменилась/удалилась/добавилась неебическая куча файлов?
Метод с merge рулит
Только если тебе похуй на остальных пользователей.
Если нет - тебе помогут команды svn log и grep.
Неужели ты не используешь svn annotate ?В повседневной жизни я использую только commit, up, status, diff, log и blame
Только если тебе похуй на остальных пользователей.Как раз, твой вариант - когда похуй на то, как это будет восприниматься.
Если нет - тебе помогут команды svn log и grep.
А в случае с merge всё предельно логично - накатили изменения, затем накатили отмену изменений. И, как приятный бонус - метод с merge можно применить в любой момент, даже если в некоторые файлах уже внесли другие, "хорошие" изменения.
Правда, в нашем случае, после говнокоммита был только один коммит, в котором изменился только один файл - и это был не тот файл, который поменял говнокоммит.
Вась, ну при чем тут trunk? Если накомитили херни в trunk, то его не нужно чинить чтоле?.. 
Оставить комментарий
kruzer25
Случайно закоммитили мегакривую ревизию. Как откатить всё назад?Пока что, единственный вариант, который приходит в голову - создать две новые папки, в одной сделать svn up -r говноревизия, в другой - svn up -r говноревизия-1; из первой - удалить всё, кроме папок .svn и скопировать всё, кроме папок .svn, из второй; после чего сделать в первой svn commit.
Но это какое-то очень кривое решение, а можно ли вернуть всё как было не через жопу?