Копирование каталога с контролем версий

Question

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

Я знаю, что он может отличаться от одного VCS к другому, но я намеренно не указываю VCS, потому что мне любопытно узнать о других случаях.

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

Однако, если мы говорим о мире DVCS, все может быть еще более неясным, поскольку каждая рабочая копия сама по себе является хранилищем. Столкнувшись с этим в bzr, я решил задать вопрос.

Позднее редактировать:

Некоторые люди спрашивали, почему я хотел бы сделать это. Вот вся история:

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

В случае с bzr я планирую перенести «основное» репо на другой сервер. Поэтому я подумал просто скопировать его туда и начать считать, что это основной репо. Я думаю, что самым безопасным является создание клона.

Answer 1

В Subversion каждая папка .svn имеет все необходимое для содержащей ее папки. А поскольку все локальные пути хранятся как относительные, вы в безопасности, копируя целые или частичные деревья за пределы исходного дерева проверки. Они будут продолжать функционировать в своих новых домах.

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

Копирование управляемых источником каталогов в других управляемых источником деревьев, с другой стороны, небезопасно . Если вы будете перезаписывать какие-либо папки .svn, скорее всего, вы повредите целевые копии.

Answer 2

В SVN это не проблема. Вы можете просто работать с копией, как если бы вы сделали вторую проверку.

Я бы порекомендовал просто проверить во второй раз. Если вам нужна копия без файлов .svn, svn export создаст ее.

Answer 3

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

Так что в основном все работает так, как вы думаете.

• Если File1 в Copy1 изменяется и File2 в Copy2 изменяется, оба могут зафиксировать
• Если File1 в Copy1 изменяется и File1 в Copy2 изменяется, кто бы ни совершает секунду, будет ошибка и ему придется сначала обновить / объединить.

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

Answer 4

Для bzr, если вы просто скопируете каталог .bzr в другое место, оно будет работать. Он не хранит никакой информации о пути, по которому он находится, и о том, на каком хосте он находится, так что вы можете скопировать его куда угодно и ожидать, что все получится, ОК.

Answer 5

Мне кажется, что GIT может также служить вашим потребностям, так как вы упоминаете, что были отключены или по дерьмовому соединению. GIT также имеет очень хорошую поддержку SVN, так что они дополняют друг друга, и вы получите прекрасную версионную файловую систему.

Answer 6

Для SVN это обычно будет работать, как уже заявили другие.

Если вы копируете между компьютерами, вы, вероятно, столкнетесь с проблемами. Например, если вы обращаетесь к своему репозиторию SVN с помощью URL-адреса file: //, скорее всего, все сломается. То же относится и к URL-адресам http: // или svn: //, где доступ к серверу может отличаться.

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

Answer 7

У меня были некоторые головные боли с SVN, когда я реорганизовал макет папки из Visual Studio. Папка, перемещенная в решении, буквально переместит папку в файловой системе, включая скрытую папку .svn. Это вызывает проблемы с фиксацией, поскольку данные .svn связаны со старым путем, и я не нашел способа повторно связать его с новым путем. SVN clean up работает нормально, но ничего не исправляет. SVN switch не позволяет вам изменить его после перемещения папки. Я смог исправить это, только удалив все папки .svn в перемещенной папке и ее подпапках, а затем заново добавил папку.

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

В соответствии с документацией SVN рекомендуется разрешить клиенту svn выполнять перемещение / создание / удаление всей вашей папки, чтобы синхронизировать все для следующей фиксации. Это не всегда приемлемо для Visual Studio. К счастью, большинство проблемных ситуаций обнаруживается во время фиксации, особенно если вы используете TortoiseSVN.

Answer 8

Это будет зависеть от VCS. В CVS я знаю, что он хранит (скрытые) каталоги внутри каждого каталога, управляемого версиями. Эти файлы, конечно, затем копируются в любую копию этого каталога.

Очень часто вы НЕ хотите копировать эти скрытые файлы, поэтому инструмент rsync имеет опцию (-C), чтобы игнорировать эти файлы так же, как это делает CVS.

Answer 9

Вы также можете просто проверить две рабочие копии (по крайней мере, с SVN), чтобы сказать work / copy1 и work / copy2 и работать над двумя версиями параллельно.

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

Answer 10

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

Но, может быть, вы можете объяснить, почему?