Как синхронизировать (объединить) с SVN репозиториями ... разработка -> производство

Question

У нас есть два репо: разработка и производство. Он был построен таким образом, чтобы тестируемые вещи входили в разработку, а затем были объединены в производство, и теперь иногда люди забывают объединиться, и они становятся несинхронными. Как лучше всего найти все изменения в репозитории для разработчиков, которых нет в репозитории?

Answer 1

Я бы не стал объединять все, но скопировал бы версию для разработки, чтобы получить новую ветку. Эта новая ветка является текущей производственной версией и замораживается. Вы можете делать исправления в нем и объединять определенные функции между веткой и разработкой. Через некоторое время разработка (транк) и производство (ветка) несколько отличаются, и вы копируете снова.

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

Я думаю, что вышеупомянутое является наилучшей практикой и широко используется. Однако, некоторые проворные методы могут быть против этого; -)

Answer 2

Проверьте рабочую версию в каталоге A. Проверьте версию разработки в каталоге B. Скопируйте все файлы из B поверх файлов в A (стараясь не копировать подкаталоги .svn). Затем выполните svn status или svn diff, чтобы увидеть, что изменилось.

Я использую Eclipse, где любой файл, который был изменен, отображается с небольшим знаком плюс, что делает его очень легко обнаружить. (Или было бы, если бы у меня было лучшее зрение и / или монитор побольше.)

Когда SVN пытается выяснить, изменился ли файл, он не отслеживает нажатия клавиш или что-то в этом роде. Он просто сравнивает текущую версию файла с кэшированной версией в каталоге .svn.

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

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