Правила работы с VSS

Материал из RSB-Doc
Перейти к: навигация, поиск

Содержание

Особенности работы с VSS

Относится ко всем файлам, хранящимся в VSS, с которыми работают программисты (за исключением ТЗ и файлов описаний).

Удаление файлов

Данная технология необходима для получения возможности сборки архивных версий. Удалять файлы необходимо без установки флажка Destroy permanently за исключением случаев, когда файл был добавлен по ошибке и не участвовал не в одной сборке или патче. В последнем случае после удаления такого файла необходимо известить руководителя отдела разработки для полного удаления этого файла из VSS.

Перенос и переименование файлов в VSS

Данная технология необходима для получения возможности сборки архивных версий. В случае необходимости переноса файла или папки в VSS необходимо придерживаться следующего алгоритма:

  1. Захватить последнюю версию файла (папки, со всеми подпапками и файлами) на свою локальную машину.
  2. На своей машине скопировать файл в рабочую директорию для новой папки VSS, куда будет переноситься файл.
  3. В VSS удалить (не перманентно) файл, который должен быть перенесен.
  4. Войти в VSS в папку, в которую должен быть перенесен файл, и добавить файл в эту папку VSS с рабочей директории вашей машины.

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

Эмуляция ветвлений в VSS

Определяет порядок организации ветвлений в VSS при исправлениях, которые должны попадать в сборки патчей.

Замечание: Делать ветки, как PVCS Version Manager, VSS из Visual Studio 6.0 не умеет

Данный документ основан на следующем примере из оригинальной документации по VSS:

--- Начало цитаты ---

Scenario #4 — A fix of the current version of a file needs to be in Beta 1, while other files HAVE been changed

Note The label-promotion feature only works if the new database format has been turned on.
Run the DDUPD.EXE utility to activate the new database format.  See DDUPD for more information.
  1. Develop and test your project in the drive toward Beta 1.
  2. At the point where you're ready to go to Beta 1, label the project "Beta 1" (or something similar).
  3. Begin working on Beta 2.
  4. You realize that the version of the file included in the Beta 1 label has a bug in it that must be fixed. Unfortunately, other files in the project have been changed and the changes have been checked in.
  5. Check out the file that needs to be fixed, make the change, then check it in, creating a new version.
  6. Label the file "Beta 1" (the same label as you labeled the project). This promotes the new version of that file into the label "Beta 1."

Now, if you do a Get of the project at Beta 1, it will get the project as it was at the date and time you labeled it "Beta 1" except that it gets the newer version of the file you just labeled individually as "Beta 1."

Scenario #5 — An older version of a file needs to be fixed and added to Beta 1

Note The label-promotion feature only works if the new database format has been turned on.
Run the DDUPD.EXE utility to activate the new database format.  See DDUPD for more information.
  1. Develop and test your project in the drive toward Beta 1.
  2. At the point where you're ready to go to Beta 1, label the project "Beta 1" (or something similar).
  3. Begin working on Beta 2.
  4. You realize that the version of the file included in the Beta 1 label has a bug in it that must be fixed. For example, the current version of the file is Version 6 and it contains changes made on the road to Beta 2 you don't want included in Beta 1.
  5. Check out the file (Version 6).
  6. Get Version 4, overwriting the local copy of Version 6.
  7. Make the changes necessary to fix the bug for Beta 1, then check in the file. This makes a Version 7 of the file (Version 4 plus the fix you've just made, minus all the changes in Versions 5 and 6).
  8. Label Version 7 of the file "Beta 1." This promotes Version 7 of the file into the label "Beta 1."
    Now, if you do a Get of the project at Beta 1, it will get the project as it was at the date and time you labeled it "Beta 1" except that it gets Version 7 of the file (the one you just labeled individually).
  9. To continue work toward Beta 2, recovering changes made in Versions 5 and 6, check out the file again (i.e., check out Version 7).
  10. Get Version 6.
  11. Overwrite the local copy of Version 7, or merge the two file versions (this ensures the local copy becomes Version 6 plus the fix you made in Version 7 for Beta 1).
  12. Make any other changes if you want, then check in the file. This creates version 8. You can now resume work toward Beta 2.

--- Конец цитаты ---

При простановке метки патча возникает вопрос: «Можно ли на исправленную версию файла, которая стала текущей, поставить метку патча?» (1) Для ответа на этот вопрос надо сравнить (в уме или непосредственно) текущую версию и версию, на которой стоит последняя метка сборки (базовая или последнего патча).
Действия в зависимости от варианта ответа.

  1. Сделать CheckOut файла. Последняя версия файла, например, 78.
  2. Открыть диалог VSS “History of …” (“Show History”) файла. Сделать Get версии файла, на которой стоит последняя метка сборки.
  3. Внести изменения в файл.
  4. Сделать CheckIn файла. При этом отметить «галочку» Keep checked out (Оставить файл захваченным). При этом создается новая версия файла, в этом примере 79.
  5. Открыть диалог VSS “History of …” (“Show History”) файла. Сделать Get версии файла до изменений, в этом примере 78.
  6. Сделать CheckIn. При этом создается новая версия файла, в этом примере 80.
  7. Открыть диалог VSS “History of …” (“Show History”) файла. Установить курсор в списке на версию файла для патча, в этом примере 79. Нажав кнопку Details, открыть диалог “History details”. В окне редактирования Label установить метку патча, например RS-Balance.3.00.03.002. Нажать кнопку Close диалога “History details” и согласиться с изменениями.
  8. Закрыть диалог VSS “History of …” (“Show History”) файла.
Личные инструменты
Пространства имён
Варианты
Действия
Навигация
Для разработки
Инструменты