Здравствуйте, Aquary, Вы писали:

A>>Да где-то начитался
A>Как найдешь — приходи..
Сразу не смог найти и было подумал, что это у меня глюк какой произошел.
А сегодня мержил две ветки, углубился в документацию к Черепаше и нашел слудеющее:

Reintegrate a branch

After the merge, all branch development has been completely merged back into the main development line. The branch is now redundant and can be deleted.

Залез в интернет и нашел следующие ссылки:
Merge

In this case you will not need the feature branch again because the new feature is now integrated into the trunk. The feature branch is redundant and can be deleted from the repository if required.

и Branch Management

When this merge is done, all future bugfixes related to this project will happen on orocos/trunk and the branch can be safely deleted: $ svn rm https://svn.mech.kuleuven.be/repos/orocos/branches/rtt/branch-name

---

А это у меня болталось с попытки ответить

A>>Смысл в том, чтобы он не болтался в папке branches ибо через год в этой папке будет "тысчимильенов" бранчей -- хрен что разберешь в этой свалке, а если удалять, то будут только актуальные ветки болтаться.
A>Ну и ладно... для того и нужны системы контроля версий — чтобы всё это хранить...
Ну так в то-то и дело, что при удалении бранча (папки) в N-ой ревизии она не будет болтаться в следующих, но просмотреть изменения сделанные (если такое понадобится) в ней будет возможно, так как SVN ведет историю изменений.
Т.е. данные хранятся, но в прошлых ревизиях -- поэтому не болтаются под ногами.

A>Не нравится захламление папки branches — переходи на CVS, там идеология работы с бранчами и метками другая.
Так вот сразу и на CVS

Здравствуйте, Aquary, Вы писали:

A>Типичный сценарий работы такой (упрощенно):

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

A>Фух... это вкраце, упрощенно, под твою ситуацию.
Это для двух-то разработчиков?! Да вы батенька шутник, однако.

Здравствуйте, stump, Вы писали:

S>Здравствуйте, Aquary, Вы писали:

A>>Типичный сценарий работы такой (упрощенно):

S>Это для двух-то разработчиков?! Да вы батенька шутник, однако.

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

Здравствуйте, ironwit, Вы писали:

I>Здравствуйте, Aquary, Вы писали:


A>> Для всего остального, причем не только в качестве побочного, используется eTraxis. Супергибкая штука, рекомендую!

I>не увидел с наскоку. интерируется с свн?

Нет. Но никто не мешает дописать такой функционал, ведь етрахис идет под GPL.