SVN - перенос проекта из директории
 

Может быть, кто-то сталкивался. Я именно с SVN никогда дела не имел.
Есть проект на сервере. Есть .svn в проекте.
в соответствующей директории
выдает урл(мертвый), где, если я понимаю верно, разработчики commit-или свою работу, и оно уходило на сервер.
Первая задача - как бы начать новый проект и всю текущую разработку утянуть к себе в качестве первой фиксации?

Добавлено через 5 минут
Виноват, заголовок не исправил на внятный.

Берите себе каталог (без .svn) и вперед. Если svn не слишком старый, то каталог будет один. Если слишком старый, копируете и выполняете в нем что-нибудь страшное вроде
Затем svn import (в репозиторий) и svn checkout (чтобы получить рабочую копию).

Да, вроде бы в новых версиях .svn стал один. Значит, старый, тут он в каждом каталоге.
А в SVN можно сделать так - коммитить в транк, подходящую revision опубликовать, а песочницу иметь локально(ну и что бы среда при запуске проекта заливала это еще куда-то на сервер, которая будет test1.domain.com)?

Добавлено через 6 минут
И еще. Удаляя .svn каталог, мы же лишаемся информации, какие именно файлы были в проекте? Просто там дофига лишнего, потом удалять что ли вручную это из проекта?

Я вспомнил правильное решение. svn export из рабочей копии. Скопирует именно файлы проекта. А svn properties в любом случае нужно будет вручную переносить (или скриптом).

Второе точно нельзя. svn - централизованная система. Т.е. репозиторий всегда один и только в него выполняется коммит изменений. "Песочница" - это что? В ней нужна история изменений? Если нужна, то точно не умеет. Используйте ветки, которые хранятся на сервере. А при необходимости сливайте ветки в транк.

Советую. Всё интуитивно понятно.

Спасибо, первым делом начал читать именно это.


Как бы все немного прояснилось.
То есть так. Сначала создадим новый репрозиторий, в него через svn export делаем экспорт текущей рабочей копии.
Потом настраиваем среду для разработчиков, которая умеет c svn работать. Утаскиваем первую revision к себе локально(то есть песочница), делаем правки. Коммитим на сервер, получаем вторую revision. Т.к. domain.com уже используется, правки сразу станут актуальными( если, конечно, оставим директорию рабочую для домена связанную с хранилищем).
Далее - как решается вопрос тестирования? Если я хочу выгрузить файлы на сервер и там запустить (учитывая, что в проекте сотни файлов, без публикации на domain.com, само собой, итд), и как решить вопрос с публикацией только основательно проверенных и стабильных revision(делать ответвления, их тестить, потом сливать)?

Может, кто-то опишет, как именно у них работают с SVN на проекте?

Не совсем. Сначала через svn export вы получаете чистую (без привязки к репозиторию) копию проекта. Затем через svn import заливаете ее в репозиторий. Далее уже примерно так, как вы описали. Через svn checkout дает первую ревизию. Дальше можно с ней работать и коммитить. Правки после успешного коммита появляются на сервере и видны всем. Перед удалением/переносом файлов/каталогов рекомендуется делать еще svn up, иначе будет ругаться на tree conflict (есть особенности версионирования каталогов).

Если правильно, то svn checkout/svn update/svn export из репозитория, автоматическая сборка всего проекта и его тестирования.

Т.е. без коммита? Ну собираете у себя и вручную заливаете. Проблем особых нет.

Ну да, можно так. Я замечу здесь, что вы путаете коммиты и release policy. Это совершенно разные аспекты управления проектами и выполняются по-разному. Можно вполне публиковать в репозиторий и непроверенные вещи, все зависит от методики управления проектом. Подробнее про release management здесь.

Официальную теорию уже читали? Конкретно у нас все изменения идут в trunk. Перед релизом объявляется feature freese, все проверяется, баги правятся (в том же trunk). В момент релиза trunk сливается в ветку current (можно копированием, можно - merge, в самом первом релизе current создается копированием trunk'а) и заводится отдельный тег. Продукт заливается на боевые сервера. После этого можно опять гадить в trunk. Ну и отдельно проходит процедура hotfix для боевой версии. В этом случае патч делается в current, из current же собирается новый релиз и потом правка портируется (мержится) в trunk. Отдельные ветки под фичу - только по мере необходимости (если там что-то большое, делается долго и ломает совместимость). Это далеко не единственный вариант управления изменениями, могут быть и различные другие. Этот был выбран под наши сценарии и нашу команду.

У меня на прошлой работе ползовались самописным решением: была написана небольшая админка на PHP которая напрямую работала с SVN сервером. Пользователь заходил, выбирал ревизию, проект собирался, проводились тесты и раскладывался на сервера (тестовые или production). Если что-то не так было на production, то можно было быстро откатится на предыдую версию.

Есть и готовые решения, например TeamCity

Исходя из того, как делал раньше, и из советов - выбрал такую структуру - девелпомент, тест, продакшн.
Все работают с девелопмент веткой, потому code freeze, потом копирование в тест ветку, там детальный тест интеграции вручную(не автоматом), автоматом тесты- в девелопмент ветке. Если ок - в продакшен, там новый тэг, если нет - доработка и повтор. Тест - на реальных данных(работа с базой), девелопмент на основе бэкапной базы. Планирую использовать SCRUM.
Если хотфиксы - то на продакшн ветке, потом svn merge изменения в девелопмент ветку.
Проект на ПХП в основном, но я это потихоньку буду менять.
1) Я так понимаю, публикацию раньше делали через получение рабочей копии( наличие каталогов .svn). Если после этого я svn export делал из рабочей копии (которую правили вручную после того, как с проекта ушли люди, и до меня) - естественно, правки вручную попали в первый revision.
2) http://svnbook.red-bean.com/ только начал, сейчас дочитал только по клиенту http://tortoisesvn.net/.
3) Если накатал класс и хочется запустить - просто заливка на сервер(локально не хочу поддерживать)
4) Если хочется посмотреть на интеграцию - то как лучше всего это организовать? Сторонний софт(TeamCity умеет?) должен извлечь рабочую копию из репозитория(именно тот revision, с которым работаю я ), загрузить куда-то, залить измененные мной файлы, я потыкаю мышкой, если все ок - то я делаю commit правок в хранилище, получаю новый revision?

Ничего не напутал, выглядит оптимально?

Что до сохранения истории. Я за время жизни с SVN так никогда и не переписывал историю, но вот буквально на днях пришлось это делать в Gitе.
Мой вам совет: если вы не испытываете особых сентиментов к прошлому вашего проекта - просто, как уже было сказано, export / import и понеслась. У меня два дня заняло удалить шесть mp4 файлов из совсем небольшого репозитория со всего 130 коммитами / двумя бранчами.