2. Показать использующийся Branch plan. Это нужно для того, чтобы более предметно давать рекомендации.
Есть главная ветка, из нее создаются ветки для разработки и починки багов. Потом они возвращаются в главную ветку.
Главная ветка следующей версии создается из главной ветки предыдущей
Я как всегда почти согласен «я не понимаю этот инструмент и его неизвестную мне теорию». Почитал я про changeset:
When you check in code into TFS, a changeset is created. A changeset is a set of files and work items associated together a time of check in. If you don't associate work items with the code, the changeset will just consist of just the set of files. The heart of this is due to the fact that the check-in process is an atomic transaction. When you perform a check in, the process tells TFS how many files and work items are going to be checked in. Assuming all the files get transferred properly into TFS, TFS will generate a changeset number. This number can be used to trace back what code files and work items were worked on.
И как мне это помогает? Чем он отличается от ревизии? Наличием привязки к work-items? Так это не принципиально для данного поста.
A Subversion client commits (that is, communicates the changes made to) any number of files and directories as a single atomic transaction. By atomic transaction, we mean simply this: either all of the changes are accepted into the repository, or none of them is. Subversion tries to retain this atomicity in the face of program crashes, system crashes, network problems, and other users' actions.
Each time the repository accepts a commit, this creates a new state of the filesystem tree, called a revision. Each revision is assigned a unique natural number, one greater than the number assigned to the previous revision. The initial revision of a freshly created repository is numbered 0 and consists of nothing but an empty root directory.
Пример понятен. Просто я еще с таким не сталкивался на практике.
Интересно, я уверен, что таких популярых проектов не так много, почему же очень много людей так востаргаются ветками гита?
А с другой стороны, релиз все равно должен собираться на билд-сервере, какая вам разница, что на машине разработчика стоит? Или вы на билд-агенте тоже ставите больше одной версии тулчейна?
В идеале хотелось бы для каждой серьезной версии иметь отдельную билд машину. А пока на одной машине могут собираться разные версии, которые собираются разными студиями.
Самый простой сценарий чтот-то поломать, создать новый проект и по-умолчанию получить не ту версию фраймворка. Наверняка есть еще и другие нюансы (особенно для c++).
Иногда нужно что то маленькое подебагировать и изменить, то очень естественно делать именно в той студии, в которой продукт был собран.
Вы уверены, что «естестественно»? Вы считали сравнительную стоимость содержания зоопарка из нескольких студий vs обновить проекты под актуальную версию?
Лично я уверен, потому что цена ошибки (особенно в работающей версии) очень велика.
Кстати, я не использую VS213 для добавления проектов, потому что TFVC (не знаю какой версии) почему то меняет файла солюшина не так как VS2012.
Это тоже очень странно. TFS вообще не трогает файлы, этим занимается только и исключительно студия. Вы обнаружили несовместимость 2013 и 2012?
Я очень уверен. Не знаю кто, но кто то создает файл ".vssscc", всякие ключи (типа SccTeamFoundationServer) в файле солюшина.
ему поставили несколько лет назад программу, она до сих пор работает. Иногда нужно что то маленькое подебагировать и изменить, то очень естественно делать именно в той студии, в которой продукт был собран. Кроме того надо учесть, что в продукте есть и c++ проекты, что несколько затрудняет перемешивать студии. Чисто для .NET solutions многие конечно используют более продвинутую версию студии.
Кстати, я не использую VS213 для добавления проектов, потому что TFVC (не знаю какой версии) почему то меняет файла солюшина не так как VS2012.
Итого:
С точки зрения клентской части нет автономного клиента TFVC, как привыкли те, кто работает с SVN.
Кроме того, каждай VS технически устанавливает своего клиента командной строки TFVC.
И что бы я совсем все понял:
При этом может быть установлен только один клиент Power Tools для Windows Explorer.
Ок.
TFVC не имеет независимого клиента командной строки, а является частью некой оболочки.
Так я про это с самого начала и говорю. Конечно сейчас я бы уточинил TFVC (а не TFS), VS оболчка (а не VS).
TFS (система контроля версий) это не совсем система контроля версий — это часть VS. После SVN это несколько напрягает. Если у меня стоит 3 студии, то чтобы понять какой TFS у меня стоит и работает требуются дополнительные усилия.
Но это вырывает мозг от осознания того что автор не понимает о чём говорит
Да, я много чего не понимаю в TFVC. Один из спосовоб что то понять, это написать пост, почитать комментарии и обсудить их с теми кто понимает.
Я не понимаю например, почему TFS.exe находится в папке каждой студии. Как скрипты писать? Студию сегодня используешь одну, завтра другую. Мне бы TFVC командую строку, которая стоит сама по себе.
Помогите понять автору.
Прежде всего, хотел бы поблагодаривать вас за ответы. Вы один из немногих, которые отвечают аргументами.
Я сам встроил в продукт открытие бага прямо в TFS с заливанием нужной информации. Это действительно хорошая вещь. Кроме того написал утилиту, которая по номеру бага складывает все присоединенные файлы в нужно мне место. Но это все-таки не совсем контроль версий.
Кстати, SVN позволяет менять не только комментарии к ревизии, но и имя автора, чего я не нашел в TFS.
TortioseSVN имеет простой и понятный поиск (и фильтр) по истории бранча
Тут я полностью согласен. Но я никогда не пользовался этими возможностями SVN, даже на проектах с 70000 коммитов.
Опишите, пожалуйста, поподробнее сценарии где Вы их используете и как.
Примеры:
— найти по имени человека и слову из названия фичи/бага (мы коммитим с полным названием фичи/бага).
— найти все коммиты нескольких людей (какой-то определенной команды).
— найти специальные ревизии (мы коммитим после количество падающих тестов и номера билдов).
— найти коммиты по какому-то слову.
Я привык создавать бранчи для любых вещей, которые потребуют какого то времени или проверок на тестовой машине.
Это делается так:
1) Идете в Pending Changes, делаете Shelve Changes при СНЯТОЙ галочке Preserve changes locally. У вас получается откат всех локальных изменений в Shelveset.
2) Дальше тестируете что хотите.
3) При необходимости сохранить делате снова Shelve без сохранения изменений локально.
4) Возвращаетесь к своим изменениям делая Unshelve с сервера.
Shelve вещь хорошая и полезная. И для некоторых сценариев работает хорошо.
Но мы используем бранчи для «длительной» разработки, что подразумевает много коммитов, тестирования бранча на тестовом компьютере и строительства билда на билд-машине. Я так понимаю, что данные сценарии shelve не поддерживает.
замержить все эти ревизии в одну ревизию версии 2.
А зачем это нужно? При мёрже у вас в истории все-равно будет одна ревизия (на момент коммита мёржа), зато всегда можно посмотреть какие из ревизий в него вошли. Или что Вы пытаетесь достичь этим?
Я привык создавать бранчи для любых вещей, которые потребуют какого то времени или проверок на тестовой машине.
Я предпочитаю, чтобы каждый программист переносил свои изменения из одной версии в другую сам. Кроме всего прочего его имя сохраняется в простой истории. Если какой та баг занял несколько ревизий в одной версии, хотелось бы чтобы все эти ревизии зашли как одна в новую ветку.
TFS этот сценарий не поддерживает, что после перехода с SVN напрягает.
Другой сценарий, когда нужно сразу много ревизий пометить как замерженные.
Третий сценарий когда надо откатить несколько ревизий на локальном диске. Этот сценарий я вообще не смог внятно реализовать.
Довольно часто некие ревизии не надо сливать из версии 1 в версию 2.
А для чего такие ревизии помечать как «смерженные»? Для этого вполне можно сделать частичный мерж и отметить все оставшиеся ревизии лейблами, типа «not to merge in production».
Нам хочется отслеживать какие ревизии уже перенесли из одной версии в другую, а какие еще нет.
Tortoise позволяет легко это видеть. Ревизии которые не надо переносить мешают (они показаны как не замерженные, но их и не надо мержить).
Поэтому мы их помечаем как «смерженные».
PowerTools это такая надстройка над tfs.exe, поэтому он ставится в зависимости от версии VS, у меня стоит несколько версий локально.
Бранчи без проблем достаются тем же tfs.exe, какие хотите и куда хотите.
Довольно часто некие ревизии не надо сливать из версии 1 в версию 2.
Все-таки получить новую ветки на локальный диск через юзер интерфейс Tortoise быстрее чем открывать студию или веб-интерфейс+командная строка.
Есть главная ветка, из нее создаются ветки для разработки и починки багов. Потом они возвращаются в главную ветку.
Главная ветка следующей версии создается из главной ветки предыдущей
Почитал я про changeset:
И как мне это помогает? Чем он отличается от ревизии? Наличием привязки к work-items? Так это не принципиально для данного поста.
Вот так определяют ревизию:
Интересно, я уверен, что таких популярых проектов не так много, почему же очень много людей так востаргаются ветками гита?
В идеале хотелось бы для каждой серьезной версии иметь отдельную билд машину. А пока на одной машине могут собираться разные версии, которые собираются разными студиями.
Самый простой сценарий чтот-то поломать, создать новый проект и по-умолчанию получить не ту версию фраймворка. Наверняка есть еще и другие нюансы (особенно для c++).
Лично я уверен, потому что цена ошибки (особенно в работающей версии) очень велика.
Я очень уверен. Не знаю кто, но кто то создает файл ".vssscc", всякие ключи (типа SccTeamFoundationServer) в файле солюшина.
ему поставили несколько лет назад программу, она до сих пор работает. Иногда нужно что то маленькое подебагировать и изменить, то очень естественно делать именно в той студии, в которой продукт был собран. Кроме того надо учесть, что в продукте есть и c++ проекты, что несколько затрудняет перемешивать студии. Чисто для .NET solutions многие конечно используют более продвинутую версию студии.
Кстати, я не использую VS213 для добавления проектов, потому что TFVC (не знаю какой версии) почему то меняет файла солюшина не так как VS2012.
Итого:
С точки зрения клентской части нет автономного клиента TFVC, как привыкли те, кто работает с SVN.
Кроме того, каждай VS технически устанавливает своего клиента командной строки TFVC.
И что бы я совсем все понял:
При этом может быть установлен только один клиент Power Tools для Windows Explorer.
TFVC не имеет независимого клиента командной строки, а является частью некой оболочки.
Так я про это с самого начала и говорю. Конечно сейчас я бы уточинил TFVC (а не TFS), VS оболчка (а не VS).
TFS клиент привязан не к студии, а к оболочке. ок. какая принципильаная разница?
SVN командной строки не привязан к оболочке студии, поэтому наличие привязки удивляет. Зачем его вообще куда то привязывать?
Я не спорю, что с этим можно жить, но после понятных клиентов SVN, установка TFS клиентов под студией напрягает и меня путает.
Get Latest приносит изменения для существующей на локальном диске ветки.
Да, я много чего не понимаю в TFVC. Один из спосовоб что то понять, это написать пост, почитать комментарии и обсудить их с теми кто понимает.
Я не понимаю например, почему TFS.exe находится в папке каждой студии. Как скрипты писать? Студию сегодня используешь одну, завтра другую. Мне бы TFVC командую строку, которая стоит сама по себе.
Помогите понять автору.
Я сам встроил в продукт открытие бага прямо в TFS с заливанием нужной информации. Это действительно хорошая вещь. Кроме того написал утилиту, которая по номеру бага складывает все присоединенные файлы в нужно мне место. Но это все-таки не совсем контроль версий.
Кстати, SVN позволяет менять не только комментарии к ревизии, но и имя автора, чего я не нашел в TFS.
Примеры:
— найти по имени человека и слову из названия фичи/бага (мы коммитим с полным названием фичи/бага).
— найти все коммиты нескольких людей (какой-то определенной команды).
— найти специальные ревизии (мы коммитим после количество падающих тестов и номера билдов).
— найти коммиты по какому-то слову.
Я так и не нашел поиск в Power Tools.
Shelve вещь хорошая и полезная. И для некоторых сценариев работает хорошо.
Но мы используем бранчи для «длительной» разработки, что подразумевает много коммитов, тестирования бранча на тестовом компьютере и строительства билда на билд-машине. Я так понимаю, что данные сценарии shelve не поддерживает.
Я предпочитаю, чтобы каждый программист переносил свои изменения из одной версии в другую сам. Кроме всего прочего его имя сохраняется в простой истории. Если какой та баг занял несколько ревизий в одной версии, хотелось бы чтобы все эти ревизии зашли как одна в новую ветку.
TFS этот сценарий не поддерживает, что после перехода с SVN напрягает.
Другой сценарий, когда нужно сразу много ревизий пометить как замерженные.
Третий сценарий когда надо откатить несколько ревизий на локальном диске. Этот сценарий я вообще не смог внятно реализовать.
Нам хочется отслеживать какие ревизии уже перенесли из одной версии в другую, а какие еще нет.
Tortoise позволяет легко это видеть. Ревизии которые не надо переносить мешают (они показаны как не замерженные, но их и не надо мержить).
Поэтому мы их помечаем как «смерженные».
Все-таки получить новую ветки на локальный диск через юзер интерфейс Tortoise быстрее чем открывать студию или веб-интерфейс+командная строка.