Что такое стеллаж в TFS?

Является ли стеллаж в TFS просто мягкой проверкой, чтобы другие члены команды могли видеть исходный код?

то есть. отложенный код не будет скомпилирован правильно?

Ответ 1

Стеллажи имеют много применений. Основные из них:

  • Контекстное переключение. Сохранение работы над текущей задачей, чтобы вы могли переключиться на другую задачу с высоким приоритетом. Скажите, что вы работаете над новой функцией, имея в виду свой бизнес, когда ваш босс работает и говорит "Ahhh! Bug Bug Bug!". и вам придется отказаться от текущих изменений в функции и исправить ошибку. Вы можете отложить свою работу над функцией, исправить ошибку, а затем вернуться и отказаться от работы над вашими изменениями позже.
  • Совместное использование изменений. Если вы хотите поделиться набором изменений кода без его проверки, вы можете облегчить доступ другим пользователям, отложив его. Это может быть использовано, когда вы передаете неполную задачу кому-то другому (бедная душа), или если у вас есть какой-то код для тестирования, который вы никогда бы никогда не проверяли тем, что кому-то еще нужно было работать. h/t другим отзывам об использовании этого для отзывов, это очень хорошая идея.
  • Сохранение прогресса. Пока вы работаете над сложной функцией, вы можете оказаться в "хорошей точке", где вы хотите сохранить свой прогресс. Это идеальное время для откладывания кода. Скажем, вы взламываете некоторые CSS/HTML, чтобы исправить ошибки рендеринга. Обычно вы натыкаетесь на нее, повторяя все возможные kludge, которые вы можете придумать, пока он не будет выглядеть правильно. Однако, как только он выглядит правильно, вы можете попытаться вернуться к себе, чтобы очистить свою разметку, чтобы кто-то еще мог понять, что вы сделали, прежде чем вы ее проверите. В этом случае вы можете отложить код, когда все будет правильно, то вы можете пойти и реорганизовать свою разметку, зная, что если вы случайно сломаете ее снова, вы всегда можете вернуться и получить свой набор изменений.

Любые другие применения?

Ответ 2

Стеллажи - это способ сохранить все изменения на вашем ящике без проверки. Изменения сохраняются на сервере. В любое более позднее время вы или кто-либо из ваших товарищей по команде может "отменить" их обратно на любую из ваших машин.

Это также отлично подходит для обзора. В моей команде для проверки мы откладываем наши изменения и отправляем электронное письмо с описанием изменения и именем набора изменений. Люди в команде могут просматривать список изменений и давать отзывы.

FYI: лучший способ просмотра полки - это следующая команда

tfpt review/shelveset: shelvesetName; userName

tfpt является частью инструментальных средств Team Foundation

Ответ 3

Это правильно. Если вы создадите полку, другие люди, получающие последние, не будут видеть ваш код.

Он помещает ваши изменения кода на сервер, который, вероятно, лучше резервную копию, чем ваш рабочий ПК.

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

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

Ответ 4

Я все время сталкиваюсь с этим, поэтому дополнительная информация о ветвях:

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

tfpt unshelve /migrate

Ответ 5

Один из вопросов, который пропущен во многих из этих обсуждений, - это то, как вы возвращаетесь обратно к ИСПОЛЬЗУЕМОЙ машине, на которой вы отложили свои изменения. Возможно, очевидно для большинства, но не для меня. Я считаю, что вы выполняете отложенные изменения отмены - это правильно?

Я понимаю, что процесс выглядит следующим образом:

  • Чтобы отложить текущие ожидающие изменения, щелкните правой кнопкой мыши проект, "Стеллаж", добавьте название полки
  • Это сохранит (или Shelve) изменения на сервере (никто не увидит их)
  • Затем вы выполните Отменить ожидающие изменения, чтобы вернуть код обратно в последнюю точку регистрации.
  • Затем вы можете сделать то, что вам нужно сделать с исходной базой обратного кода
  • Вы можете безотлагать изменения в любое время (может потребоваться некоторое слияние)

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

Ответ 6

@JaredPar: Да, вы можете использовать Shelvesets для обзоров, но имейте в виду, что полки могут быть перезаписаны самим/другими и, следовательно, не долговечны. Поэтому для релевантных релевантных обзоров вы никогда не должны использовать Shelveset в качестве базы, а скорее checkin (Changeset). Для неофициального обзора это нормально, но не для официального (например, FTA релевантного) обзора!

Ответ 7

Если вы используете Gated-сборки, когда запускается сборка, она создает полку вашего рабочего пространства, которое отправляется для сборки. Если сборка завершается неудачно, полка отклоняется. Если сборка выполнена успешно, создается набор изменений и привязывается к TFS. В любом случае человеку, выполняющему эту процедуру check-in/build, придется согласовать рабочее пространство, что так же просто, как выполнить Get Latest.