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

В 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 считает его совершенно новым. Кроме того, он не так эффективно сохраняет содержимое файла, сохраняя отличия от предыдущей версии.

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

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

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

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

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