Синхронизация библиотеки / репозитория проекта

Question

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

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

Answer 1

Опция, которая может работать для вас, - это использовать svn: внешнюю ссылку на библиотеку. Помечая проект, вы можете сделать одну из двух вещей:

• Обновите svn: external для ссылки на конкретную версию библиотеки; OR
• Обновите svn: external для ссылки на новый тег, который вы делаете в библиотеке.

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

Answer 2

Вы можете найти поршень предлагает решение

Он в основном используется для импорта плагинов ruby ​​на rails, но я не понимаю, почему он не должен работать ни для каких хранилищ subversion.

В основном это то, что он делает:

• svn export последняя версия удаленного пути
• отправить эти файлы в локальный svn, как если бы они были локальными файлами
• прикрепить метаданные в виде свойств svn об удаленном пути и ревизии

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

если вы хотите обновить локальную копию библиотеки до последней удаленной версии, просто наберите piston update

Вы также должны иметь возможность просматривать историю обновлений, просто просматривая метаданные - свойства svn имеют версии, как и файлы, и все остальное

Answer 3

Я думаю, что если бы я собирался сделать это, я бы использовал теги. Было бы довольно легко написать скрипт, который бы помечал оба хранилища одним и тем же идентификатором каждый раз, когда вы обновляли библиотеку и использовали ее в проекте. Затем, если вам нужно откатиться до предыдущей версии, вы просто увидите, какой был ее самый последний тег, и откатите библиотеку до этой версии.

ОБНОВЛЕНИЕ: Извините, я уже некоторое время на Меркурии и забыл, что Subversion напрямую не поддерживает тегирование. Предполагая, что вы используете обычную структуру каталогов Subversion

/
  /trunk
  /tags
  /branches

вам просто нужно запустить

svn copy trunk/ tags/TagName

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

Answer 4

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