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

Question

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

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

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

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

Позже отредактирую:

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

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

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

Answer 1

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

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

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

Answer 2

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

В общем, это работает так, как вы думаете.

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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

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

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

Answer 9

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

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

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

Answer 10

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