Не будет дублировать хранилище, нет. SVN эффективно хранит свои данные в виде дерева версий файловой системы плюс набор файловых данных, а trunk / include / abc.h будет указывать на те же данные файла, что и теги / myTag / include / abc.h.
Теперь будет два пути для доступа к одной и той же копии кода, да, но версия тегов будет исправлена в той ревизии, в которой вы сделали копию. Если вы продолжите фиксировать транк / include / abc.h, теги / myTag / include / abc.h останутся прежними.
Тем не менее, вы всегда можете сослаться на версию кода в транке, запомнив номер ревизии: вы можете просто записать где-нибудь, что release-1.0.0 = trunk @ 12345. Тем не менее, теги - это более простой способ запомнить это, и они будут содержать метаданные, связывающие их с конкретной ревизией транка, из которой вы их скопировали.
Ваше последнее изменение: я не уверен на 100%, что вы подразумеваете под «все предыдущие или последние», но вам следует сохранить версию, которую вы фактически выпустили. Возможно, вы также захотите создать стабильную ветку из вашего выпуска, чтобы вы могли делать исправления-релизы из той же версии кода, а не из ствола. Там нет (или очень мало) затрат на хранение для маркировки абсолютно всего на транке. Если вы имеете в виду, можете ли вы получить доступ к журналу фиксации для файлов, начинающихся с тега, то да, вы можете - тег фактически содержит всю историю до этого момента.
Извините, только что заметил это:
Когда я извлекаю проект из существующего хранилища, создаются три папки: ветви, теги и ствол.
Нет - вам нужно только проверить ствол или ветку, над которой вы работаете. Вы не должны проверять все это, нет, или вы получите все дублированное на вашем диске. Проверка корня хранилища - плохая идея, и в дистрибутиве Subversion есть даже плагин Apache, который вы можете установить, чтобы явно запретить его.