Копирование каталога с контролем версий
Мне интересно, нормально ли копировать каталог, находящийся под контролем версий, и начать работать с обеими копиями.
Я знаю, что она может отличаться от одной VCS к другой, но я намеренно не указываю никакой VCS, так как мне любопытно узнать о разных случаях.
Недавно я разговаривал с коллегой о том, как сделать это в SVN. Я думаю, что все должно быть в порядке, но я все еще не уверен на 100%, так как я не знаю, что именно SVN хранит в рабочей копии.
Однако, если мы говорим о мире DVCS, все может быть еще более непонятным, поскольку каждая рабочая копия сама по себе является хранилищем. Столкнувшись с этим в bzr, я решил задать вопрос.
Позже отредактируйте:
Некоторые люди спрашивали, почему я хотел бы сделать это. Вот вся история:
В случае с SVN это произошло потому, что, находясь вне офиса, подключение к серверу SVN было очень медленным, поэтому я и мой коллега решили проверить источники только один раз и сделать локальную копию. Это то, что мы сделали, и это работало хорошо, но я все еще задаюсь вопросом, гарантированно ли это работает, или это просто случилось.
В случае с bzr я планирую перенести "основной" репо на другой сервер. Поэтому я подумал просто скопировать его туда и начать считать, что это основной репо. Я думаю, что самый безопасный способ сделать клон.
10 ответов
В Subversion каждая папка.svn имеет все необходимое для содержащей ее папки. А поскольку все локальные пути хранятся как относительные, вы в безопасности, копируя целые или частичные деревья за пределы исходного дерева извлечения. Они будут продолжать функционировать в своих новых домах.
Я часто копирую поддеревья из своего ствола снаружи, переключаю новые копии на другие ветви / теги и делаю все, что необходимо для "клонированных" локальных копий. Таким образом, если по какой-либо причине мне нужно вернуться назад и что-то сделать в багажнике, у меня есть нетронутая копия багажника в исходном местоположении.
Копирование управляемых исходным кодом каталогов в другие управляемые исходным кодом деревья, с другой стороны, небезопасно. Если вы будете перезаписывать какие-либо папки.svn, скорее всего, вы повредите целевые копии.
Я делаю это время от времени в SVN, и у меня не было никаких проблем. Я считаю, что в SVN хранится только исходное состояние каталога и указатель на каталог репозитория, из которого он получен.
Так что в основном все работает так, как вы думаете.
- Если File1 в Copy1 изменяется и File2 в Copy2 изменяется, оба могут зафиксировать
- Если File1 в Copy1 изменится, а File1 в Copy2 изменится, тот, кто фиксирует второй, будет иметь ошибку и должен будет сначала обновить / объединить.
Для тех, кто интересуется, почему мне пришлось копировать, у меня были проблемы с проверками по нашей сети, которые были очень медленными при первой проверке одного из наших более крупных проектов. Напротив, простое копирование с другого компьютера, казалось, давало мне все те же преимущества.
В svn это не проблема. Вы можете просто работать с копией, как если бы вы сделали вторую проверку.
Я бы порекомендовал просто проверить во второй раз. Если вам нужна копия без файлов.svn, svn export создаст ее.
Для bzr, если вы просто скопируете каталог.bzr в другое место, он будет работать. Он не хранит никакой информации о пути, по которому он находится, и о том, на каком хосте он находится, так что вы можете скопировать его куда угодно и ожидать, что все получится, ОК.
Вы также можете просто проверить две рабочие копии (по крайней мере, с SVN), чтобы сказать work / copy1 и work / copy2 и работать над двумя версиями параллельно.
Интересно, чего же вы пытаетесь достичь, так как копирование может быть не лучшим решением вашей проблемы.
Это будет зависеть от VCS. В CVS я знаю, что он хранит (скрытые) каталоги внутри каждого каталога, управляемого версиями. Эти файлы, конечно, затем копируются в любую копию этого каталога.
Это так часто, что вы НЕ хотите копировать эти скрытые файлы, когда инструмент rsync имеет опцию (-C), чтобы игнорировать эти файлы так же, как это делает CVS.
У меня были некоторые головные боли с SVN, когда я реорганизовал макет папки из Visual Studio. Папка, перемещенная в решении, буквально переместит папку в файловой системе, включая скрытую .svn папка. Это вызывает проблемы с фиксацией, потому что .svn данные связаны со старым путем, и я не нашел способа повторно связать его с новым путем. SVN clean up работает нормально, но ничего не исправляет SVN switch не позволяет изменить его после перемещения папки. Я смог исправить это, только удалив все .svn папки в перемещенной папке и ее подпапках, затем повторно добавьте папку.
Проблема с этим исправлением заключается в том, что вы теряете свой след версии в этих файлах, потому что SVN видит его как совершенно новый. Кроме того, он не хранит содержимое файла так же эффективно, сохраняя diff из предыдущей версии.
Согласно документации SVN, рекомендуется разрешить svn клиент, чтобы сделать всю вашу папку перемещать / создавать / удалять, чтобы держать все в синхронизации для следующей фиксации. Это не всегда приемлемо для Visual Studio. К счастью, большинство проблемных ситуаций обнаруживается во время фиксации, особенно если вы используете TortoiseSVN.
Для SVN это обычно будет работать, как уже заявили другие.
Если вы копируете между компьютерами, вы, вероятно, столкнетесь с проблемами. Например, если вы обращаетесь к своему репозиторию SVN с помощью URL-адреса file://, скорее всего, все сломается. То же относится и к URL-адресам http:// или svn://, где доступ к серверу может отличаться.
Чтобы оставаться в безопасности, я бы просто посмотрел на новом месте. Если у вас есть много несвязанных изменений в том, что вы хотите иметь в новом рабочем каталоге (как правило, плохая идея), вы можете затем использовать rsync для копирования вашего исходного кода без внесения в каталоги.svn.
Я бы посоветовал не делать этого, поскольку вы обходите механизм контроля версий.
Но, может быть, вы можете объяснить, почему?
Мне кажется, что GIT может также служить вашим потребностям, так как вы упоминаете об отключении или по дерьмовому соединению. GIT также имеет очень хорошую поддержку SVN, так что они дополняют друг друга, и вы получите прекрасную версионную файловую систему.