svn

Скажем, вы принимаете какой-то код, существующий в разных версиях, без контроля версий (возможно, с некоторыми резервными копиями). Существуют ли какие-либо инструменты, которые позволяют анализировать отношения (больше, чем различия) или позволяют реконструировать историю в системе управления версиями?

Если вы загрузите его в Subversion, можете ли вы сделать лучше, чтобы обозначить лучшую версию как базовую версию, а остальные как ветки?

Вы должны были бы получить это право с самого начала? Нравится загружать резервные копии перед последними версиями?

Что, если позже вы обнаружите, что один файл в одной ветке является переименованной версией файла в другой ветке?

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

(Добавлено 13 ноября) Существуют ли какие-либо системы контроля версий, которые лучше, чем Subversion для этого? т.е. поиск взаимосвязей, их создание после того, как файлы будут в системе и общая поддержка слияния?

svn branch merge

Olav 11 Ноя 2009 в 10:41

2 ответа

Вы можете попробовать DVCS, например Bazaar, Mercurial или Git.

Инициализируйте репозиторий в каждой версии вашего кода, добавьте весь код в первую фиксацию, а затем объедините разные версии вместе в одну ветку. В DVCS каждая ветвь может быть объединена с любой другой ветвью.

Результат можно импортировать в subversion, если вы хотите сохранить различия в истории, в противном случае вы можете просто удалить информацию DVCS и проверить объединенный результат в свой SVN.

Oliver Friedrich 11 Ноя 2009 в 10:50

В чем преимущество над Subversion? У меня нет особых причин использовать распределенный контроль версий. Думаю, в VSS, который я знаю лучше всего, было бы сложно объединить что-то, что раньше не было разветвленным. Хотя основная проблема для меня — получить информацию в системе контроля версий.

–

Olav

11 Ноя 2009 в 12:12

Именно потому, что в dvcs можно объединять деревья, которые до этого не были разветвленными. Эта гибкость позволяет удовлетворить потребности здесь. Ему не нужно менять целиком, но для этой задачи он мог бы дополнительно использовать dvcs, после чего удалить dvcs-метаданные. Работа выполнена, исходники в SVN готовы.

–

Oliver Friedrich

11 Ноя 2009 в 18:41

Но это не имеет ничего общего с концепцией dvcs, не так ли? Также я не хотел бы делать эту работу заранее.

–

Olav

13 Ноя 2009 в 11:37

Конечно, это так, поскольку концепция dvcs позволяет вам объединять все со всем, поэтому она позволяет вам обрабатывать отдельные каталоги как разные ветки, которые можно объединять. Вам не нужно переходить с svn на dvcs, но используйте dvcs как инструмент, который поможет вам выполнить свою задачу.

–

Oliver Friedrich

13 Ноя 2009 в 14:02

Похоже, вы хотите импортировать материал в свой репозиторий таким образом, чтобы «симулировать», как выглядела бы история, если бы она все время находилась под контролем версий (например, зафиксируйте версию 1 файла, затем версию 2). , и т.д.).

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

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

Michael Hackner 11 Ноя 2009 в 17:54

Важная вещь - это отношения - история ветвления/слияния. (Не файл/история изменений). И да, я хотел бы не делать много ручной работы заранее

–

Olav

13 Ноя 2009 в 11:31

Любые инструменты для анализа расходящегося кода, перенос его в исходный контроль (Subversion)

2 ответа

Похожие вопросы

Новые вопросы