cvs: спасение рядового head

> ps: выкрики a'la 'cvs не нужен' & K лучше всего оставить при себе - они не интересны.

CVS не нужен, а знание нормальных [D]VCS - нужно. Решение проблемы: сковертировать CVS-репу во что-нибудь приличное, и вопрос отпадет сам ({svn,hg,git} co -r).

сделать export нужной даты, перезаписать файлы working copy, а потом commit ?

Проще всего восстановить весь CVS реп из бэкапов (но клиенские программы сойдум с ума - самые новые номера версионных файлов будут меньше локальных).

Если это не желательно - придется делать новый коммит старого состояния.

* cvs diff -u D "дата хорошего состояноя" -r HEAD | patch -p1 -R; cvs commit -m "роллбэк до дата"

* ИЛИ если проект не использует модули CVS (ядвляется 1 модулем) - можно натравить на него git cvsimport. В итоге получится git репозиторий, в котором видны все гадские коммиты. Их можно откатить средствами git и потом git cvsexportcommit закоммитить в CVS (ну или еще как-нить).

* ИЛИ если есть врожденная неприязнь к git - использовать cvsps для тех же целей.

> сделать export нужной даты, перезаписать файлы working copy, а потом commit ?

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

// wbr

> * cvs diff -u D "дата хорошего состояноя" -r HEAD | patch -p1 -R; cvs commit -m "роллбэк до дата"

да, этот вариант вполне подошёл, спасибо. думаю, вопрос закрыт.

// wbr

> cvs diff -u D "дата хорошего состояноя" -r HEAD | patch -p1 -R; cvs commit -m "роллбэк до дата"

С бинарными файлами будет облом?

> сделать export нужной даты, перезаписать файлы working copy, а потом commit ?

Гнилой вариант. Допустим человеки насрали (добавили-add) боольшую кучу файлов, которых не было до нужной ревизии. После коммита весь этот мусор останется

> Гнилой вариант. Допустим человеки насрали (добавили-add) боольшую кучу файлов, которых не было до нужной ревизии. После коммита весь этот мусор останется

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

// wbr

> С бинарными файлами будет облом?

правило номер 1: "не храните бинарный файлы в VCS" :)

// wbr

а в cvs как в svn revert нету?

> а в cvs как в svn revert нету?

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

// wbr

> правило номер 1: "не храните бинарный файлы в VCS" :)

Категорически согласен, но жизнь многогранна и всё такое... Я сам по своей инициативе ещё ни одного бинарника ни в одну репу не добавил ;)

> правило номер 1: "не храните бинарный файлы в CVS" :)

obvious fix

> причём без установки sticky date, как это делает cvs checkout -D <date> <project>.

Чем плохо? так и делал - откатывал на нужную дату потом ресет sticky(-A опция, вроде) и заливка. Никаких лишних телодвижений.

> > cvs diff -u D "дата хорошего состояноя" -r HEAD | patch -p1 -R; cvs commit -m "роллбэк до дата"

> С бинарными файлами будет облом?

В таком виде - да, а если 'cvs diff -u -a' - то нет :] (это не очень красивый ключик, вроде есть более красивый)

Я бы сделал так:

cvs up -D date
cvs tag -d TMP
cvs tag TMP
cvs up -A
cvs up -j HEAD -j TMP
cvs tag -d TMP
cvs ci

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

cvs up -j HEAD -D date
cvs ci

сделали бы совершенно то же самое.

PS. Вам не нравится cvs? Вы просто не умеете его готовить.