Я проверил локальную рабочую копию кодовой базы, которая находится в репозитории svn. Это большой Java-проект, для разработки которого я использую Eclipse. Конечно, Eclipse строит все на лету, по-своему, все двоичные файлы заканчиваются на [root проекта] / bin . Это прекрасно для меня, для разработки, но когда сборка выполняется на сервере сборки, она выглядит совсем иначе (сборка maven, двоичные файлы оказываются в другой структуре каталогов и т. Д.).
Иногда мне нужно пересоздать среду сервера сборки в моей локальной системе разработки для отладки сборки или чего-то еще, поэтому я обычно заканчиваю тем, что загружаю совершенно новую рабочую копию в новое рабочее пространство и запускаю сборку оттуда (предотвращает загромождение мое рабочее пространство разработки со всеми артефактами сборки и загрязнением рабочей копии). Конечно, иногда меня интересует запуск полной сборки кода, который я пока не хочу регистрировать, поэтому я вручную скопирую рабочую область «разработка» в рабочую область «сборка». Помимо того, что я трачу много дополнительного времени на копирование большого количества файлов, которые мне на самом деле не нужны (просто накладываю новый поверх старого), это также портит мои метаданные svn, а это означает, что я не могу проверить изменения из этой сборки рабочая копия », и мне часто приходится перезагружать код, чтобы вернуть его в известное состояние.
Так что я думаю, что я делаю свою рабочую копию svn локальным репозиторием git, а затем "извлекаю" код разработки из рабочего мастера svn copy / git master в локальную рабочую область сборки. Затем я могу собрать, отменить свои изменения, получить все преимущества рабочей копии с контролем версий в рабочей области сборки. Затем, если мне нужно внести изменения в сборку, вставьте их обратно в мастер git (который также является рабочей копией svn), затем проверьте их в основном репозитории svn.
|-------------|
|main svn repo| <------- |---------------------|
|-------------| |svn working copy | <------- |--------------------|
| (svn dev workspace/ | | non-svn-versioned |
| git master) | | build workspace |
|---------------------| | (git working copy) |
|--------------------|
Просто переключить все на git, очевидно, было бы лучше, но в большой компании слишком много людей, использующих svn, слишком дорого, чтобы все изменить и т. Д. Мы сейчас застряли с svn в качестве основного репо.
Кстати, я знаю, что есть плагин maven для Eclipse, и все, в основном мне интересно знать, есть ли способ сохранить рабочее пространство, которое является одновременно рабочей копией git и рабочей копией svn. На самом деле любая распределенная система контроля версий, вероятно, будет работать (возможно, hg?). Совет? Как все остальные справляются с такой ситуацией, когда им приходится управлять процессом сборки "разработки" и процессом сборки "производства"?