Эти две ревизии содержат, по крайней мере, один общий файл.
В этом случае не могу откатить вторую ревизию с сообщением: TF203015: The item «fileName» has an incompatible pending change.
Проверял на двух ревизиях с одним и тем же файлом.
А теперь сделайте простой мысленный эксперимент: представьте себе, что на CS, который вы откатываете, завязан CS… из другой задачи. Это, надо сказать, совершенно нормальная ситуация в живой системе. И зачем вам теперь операция «откатить все CS по одному WI»?
Мой опыт данного проекта, говорит о том, что довольно редко ревизии одного WI завязаны на ревизии другого. А если это так, то почему бы этим не пользоваться?
И нет, вы не правы, TFS прекрасно позволяет откатить любое количество CS, просто это надо делать по одному CS за раз.
Секундочку.
Я хочу откатить только на локальном компьютере, что бы проверить. Я не хочу делать чек-ин, пока не проверю. Этого TFS не позволяет (в моем реальном случае между подозрительными ревизиями находились нормальные, которые я не хотел откатывать).
пример из жизни:
— утро (раннее утро)
— в стабильной ветке проблема, которая не дает выпустить билд
— вместо кофе открываю историю
— прохожу последние ревизии
— нахожу кандидата, который создает проблему
— откатываю его, что бы проверить у себя на компьютере
— все равно вижу проблему, потому что эта ревизия завязана на другую ревизию этого же дефекта
— хочу откатить вторую ревизию этого дефекта, что бы только проверить свои подозрения
— между этими двумя ревезиями есть другие ревизии ==> TFS не может откатить две такие ревизии
— дальше идет игра слов, которая не будет интересна в данном контексте
когда я ищу проблему, нет смысла откатывать до стабильной линии: там то все работает.
мне нужно откатывать определенные куски (дефекты), что бы понять какой из них привел к проблеме.
Читайте Continuous Delivery.
Можете посоветовать, что то конкретное?
Просто тесты (быстрые тесты) мы запускаем конечно же на каждый коммит (чек-ин), но даже этот процесс (очередь, компиляция, выполнение тестов) может занять десятки минут.
Все тесты могут бежать много времени (часы) и мы не можем себе позволить «попадали тесты — код не попал в репозиторий — красота». А иногда важнее отдать версию, даже с падающим тестом.
Вы же помните, что все изменения должны быть атомарными?
Помню. Только не знаю где есть такая команда, в которой это работает. Может послать туда резюме, раз TFS не поддерживает реальность? ;)
мониторинг изменений, чтобы обнаружить проблемы на раннем этапе (делается все-таки программистом)
Это делается не программистом, а тимлидом (который, конечно, тоже программист, но это другая часть его функций). И правильно это делать через code review.
Я местный code review еще «не проходил». Так что все впереди. Хотя все равно не понимаю, как это поможет мне реализовать сценарий описанный выше.
Это делается не по WI, а по всей истории кода сразу.
Так я про это и пишу.
Например, попадали тесты, открываешь историю, находишь подозрительную ревизию, откатываешь все ревизии этого дефекта, проверяешь этот тест локально. Красота!
Жалко TFS данного сценария не поддерживает совсем :(.
я начинаю от общего к частностям: вперва сколько ревизий для этого дефекта, где были изменения, какие были изменения.
И зачем это нужно программисту?
У меня есть такие примеры:
— мониторинг изменений, чтобы обнаружить проблемы на раннем этапе (делается все-таки программистом)
— расследования всяких сложных проблем: что то пошло не так (какие то тесты стали падать, перформанс пострадал, интеграция с другой программы барахлит).
В SVN мы работали с бранчами, создавали сколько надо, жили в них сколько надо, возвращали в родную ветки без особых проблем (есть минимальные требования конечно к поддрежки «долгих» веток).
Наверно единственной серьезной проблемой было перенос ветки в главную ветку другой версии.
Именно так мы пытаемся работать в TFS, но из-за сложностей свитча, этот путь не такой легкий и приятный.
Эти две ревизии содержат, по крайней мере, один общий файл.
В этом случае не могу откатить вторую ревизию с сообщением: TF203015: The item «fileName» has an incompatible pending change.
Проверял на двух ревизиях с одним и тем же файлом.
Мой опыт данного проекта, говорит о том, что довольно редко ревизии одного WI завязаны на ревизии другого. А если это так, то почему бы этим не пользоваться?
Секундочку.
Я хочу откатить только на локальном компьютере, что бы проверить. Я не хочу делать чек-ин, пока не проверю. Этого TFS не позволяет (в моем реальном случае между подозрительными ревизиями находились нормальные, которые я не хотел откатывать).
— утро (раннее утро)
— в стабильной ветке проблема, которая не дает выпустить билд
— вместо кофе открываю историю
— прохожу последние ревизии
— нахожу кандидата, который создает проблему
— откатываю его, что бы проверить у себя на компьютере
— все равно вижу проблему, потому что эта ревизия завязана на другую ревизию этого же дефекта
— хочу откатить вторую ревизию этого дефекта, что бы только проверить свои подозрения
— между этими двумя ревезиями есть другие ревизии ==> TFS не может откатить две такие ревизии
— дальше идет игра слов, которая не будет интересна в данном контексте
Может на последние купили и на железо не осталось :)
мне нужно откатывать определенные куски (дефекты), что бы понять какой из них привел к проблеме.
Но даже там не все так просто: просто железку наш айти не купит, а еще нужно место найти, кондиционер и т.д.
так я так и ищу: откатываю подозрительные дефекты, все ревизии не имеет смысла откатывать: я и так знаю, что тесты не падали.
Читайте Continuous Delivery.Можете посоветовать, что то конкретное?
Просто тесты (быстрые тесты) мы запускаем конечно же на каждый коммит (чек-ин), но даже этот процесс (очередь, компиляция, выполнение тестов) может занять десятки минут.
Все тесты могут бежать много времени (часы) и мы не можем себе позволить «попадали тесты — код не попал в репозиторий — красота». А иногда важнее отдать версию, даже с падающим тестом.
Помню. Только не знаю где есть такая команда, в которой это работает. Может послать туда резюме, раз TFS не поддерживает реальность? ;)
Я местный code review еще «не проходил». Так что все впереди. Хотя все равно не понимаю, как это поможет мне реализовать сценарий описанный выше.
Так я про это и пишу.
Например, попадали тесты, открываешь историю, находишь подозрительную ревизию, откатываешь все ревизии этого дефекта, проверяешь этот тест локально. Красота!
Жалко TFS данного сценария не поддерживает совсем :(.
и делается это одним из обычных программистов.
У меня есть такие примеры:
— мониторинг изменений, чтобы обнаружить проблемы на раннем этапе (делается все-таки программистом)
— расследования всяких сложных проблем: что то пошло не так (какие то тесты стали падать, перформанс пострадал, интеграция с другой программы барахлит).
Просто я делюсь опытом, который может быть будет полезен тем, кто работает на SVN, но его окучивают «продавцы» от Microsoft.
А annoate я использую когда надо быстро найти, кто написал этот фрагмент кода, и в рамках какой деятельности.
к сожалению ;(
Но мне бы на пальцах.
В SVN мы работали с бранчами, создавали сколько надо, жили в них сколько надо, возвращали в родную ветки без особых проблем (есть минимальные требования конечно к поддрежки «долгих» веток).
Наверно единственной серьезной проблемой было перенос ветки в главную ветку другой версии.
Так зачем для данного сценария работа GIT?