Переупорядочивание проекта после проверки SVN

Question

Это, вероятно, СВН 101, но я должен спросить:

Я работаю над проектом, который имеет вид хромую структуры каталогов. Чтобы получить его и запустить в моей любимой среде IDE, после того, как я проверю проект, я копирую весь проект в другой каталог и перемещаю вещи по своему вкусу (и моим IDE).

Итак, мой основной вопрос заключается в следующем: могу ли я безопасно редактировать/обновлять/объединять файл, который находится в другом каталоге strcuture, чем структура каталогов репозитория?

Е.Г., если я проверить /home/me/dev/proj/index.jsp, а затем скопировать его (и его .svn метаданные) в /home/me/dev/better-proj/web/index.jsp, тот факт, что index.jsp находится в другом каталоге должно быть в порядке с учетом его статуса SVN, не так ли? Неправильно? Или я просто прошу о неприятностях?

Answer 1

Вы просите о неприятностях. Много неприятностей. Если вы попытаетесь обновить корень, в результате вы получите полное безумие (много препятствий, «восстановленных» файлов и т. Д.). Также, как вы копируете метаданные отдельного файла? Метаданные SVN хранятся в папке .svn, которая находится в каталоге. Вы можете указать , чтобы обновлять и фиксировать отдельные каталоги, которые не были изменены (т. Е. Сама директория была перемещена или переименована, но все ее дочерние элементы точно такие же, как в репо). Опять же, вы не можете. Это опасно.

Вы должны либо настроить свою среду IDE, чтобы она соответствовала тому, как проект предназначен для использования/создания, либо перестроить проект в соответствии с тем, как он должен использоваться/построен. В последнем случае вы захотите исследовать подкоманду svn move (то есть svn help move). Возможно, также будет полезен GUI для SVN, например TortoiseSVN (для окон), если вы собираетесь много перестраивать.

Answer 2

Я неправильно понял ваш вопрос. Я думал, что вы ищете что-то вроде команды перемещения SVN. (see these questions)

Но это, по-видимому, не то, что вы ищете.

Я думаю, что вы просите о проблемах с предлагаемым рабочим процессом. Это действительно не очень хорошая идея. Почему бы вам просто не переместить рабочие элементы в svn?

Answer 3

Итак, вы работаете с проектом в другой структуре, чем другие в своей команде? Я не уверен, как это работает честно. Я хотел бы поговорить со всеми участниками и использовать svn: перейдите, чтобы получить все файлы с историей в тех местах, где все могут договориться.

Answer 4

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

Есть ли причина, по которой вы не можете использовать svn move для реорганизации проекта в репозитории? вы не потеряете историю таким образом, и вы сделаете свою жизнь намного легче.

Answer 5

Если пункт назначения все еще находится в вашей рабочей копии, используйте svn move (documentation). В любом случае, вы не делаете когда-либо хотите управлять метаданными .svn, так как это приведет к конфликтам и общей головной боли.

Если адресат является рабочей копией другого хранилища, вы хотите сделать svn export (documentation) на исходном репо с последующим svn add (documentation) на репо назначения.

Также стоит прочитать: Subversion Basic Work Cycle