так это проблема Svn — что у неё нет другого типа данных :)
по факту же тэг и ветка (безотносительно конкретной СКВ) — это две принципиально разные сущности
то, что в Svn — это просто файловые пути в репозитории + набор договоренностей, которые невозможно enforce — это на самом деле реальная засада! думать мешает, мешает простраивать нормальное отображение между workflow и toolflow, мешает обучать.
Вам говорят «эта машина способна проехать тысячу километров на одном литре бензина». Вы говорите «расскажите подробнее пример из практики, как вы проехали 1000 километров на литре бензина».
что тут можно «рассказать»?
«Да, я тоже проехал 1000 километров и потратил 1 литр бензина», что ли?
по-моему, этот «рассказ» будет отдавать имбецильностью
это не просто реально, а если полноценный и бескомпромиссный двунаправленный гейтвей между Subversion и Git
входит непосредственно в дистрибутив и называется «git svn» :)
то есть
вы можете склонировать полную (или часть) историю изменений svn-репозитория и превратить её в гитовый репо.
соответственно возникнет двунаправленная связь между ветками в svn и ветками в этом git-репо
дальше можно а) свободно работать в гит-репо без ограничений. затем внесенные изменения на ветке закоммитить обратно в Subversion.
б) обновлять (инкрементально) содержимое гит-репо, доимпортируя новые коммиты из svn-репо. при этом внутри гита будет обычный merge-tracking, который позволит эти svn-коммиты безболезненно накатить.
то есть теоретически ваши коллеги могут не подозревать, что вы не пользуетесь Subversion :)
лучше бы там стояла искусственная задержка на две минуты, чтобы не было иллюзий.
по факту же тэг и ветка (безотносительно конкретной СКВ) — это две принципиально разные сущности
то, что в Svn — это просто файловые пути в репозитории + набор договоренностей, которые невозможно enforce — это на самом деле реальная засада! думать мешает, мешает простраивать нормальное отображение между workflow и toolflow, мешает обучать.
«тэги — это ветки, но в отличие от веток, в них никто не коммитит».
кроме того, они нужны для совершенно другого
у них вообще разный набор операций
это разные «типы данных»
зачем же?
дурацкая получилась бы статья :)
так что ша, дружок
как там Предводитель Акира говорит — когда напишешь лучше — заходи
вы же не просто так делаете push, а проектируете поток своих изменений
squadette.habrahabr.ru/blog/40462/
почитайте
так что ша, дружок
как там Предводитель Акира говорит — когда напишешь лучше — заходи
а гитовская, обновляя рефы по своему протоколу — теснее ориентирована с самой идеей хранения истории изменений
расскажите детально какой-нибудь случай из жизни!
Вы чего сказать-то хотите? :)
теоретически я должен чувствовать сострадание и уважение ко всем живым существам
но я, знаете, человек слабый
и поэтому мне сложно всерьёз воспринимать людей со столь чётким лейблом «Pioneriis Vacuumcephali» на лбу :)
постарайтесь написать другой комментарии, более умный :)
а этот сотрите, не позорьтесь :)
я не знаю, что на это ответить
могу головой об стену побиться, если вы все этого хотите
«будет, потому что может», и «не будет, потому что иначе не может» — какая пропасть в мировоззрении есть между этими вещами
ну ничего, я верю в хабр
акиры не подведут
никто не мешает в Subversion коммитить один раз в неделю с комментарием «Уфф, пятница» :)
Вам говорят «эта машина способна проехать тысячу километров на одном литре бензина». Вы говорите «расскажите подробнее пример из практики, как вы проехали 1000 километров на литре бензина».
что тут можно «рассказать»?
«Да, я тоже проехал 1000 километров и потратил 1 литр бензина», что ли?
по-моему, этот «рассказ» будет отдавать имбецильностью
молодец, прошёлся по всем комментом с минусом ;)
«сообразительный парень»!
P.S.: карму минуснуть забыл!
но можно засетапить так, что дизайнеры сидят под svn/tortoisesvn, а девелоперы пользуются гитом
я думаю, что рано или поздно мы у себя так и сделаем
входит непосредственно в дистрибутив и называется «git svn» :)
то есть
вы можете склонировать полную (или часть) историю изменений svn-репозитория и превратить её в гитовый репо.
соответственно возникнет двунаправленная связь между ветками в svn и ветками в этом git-репо
дальше можно а) свободно работать в гит-репо без ограничений. затем внесенные изменения на ветке закоммитить обратно в Subversion.
б) обновлять (инкрементально) содержимое гит-репо, доимпортируя новые коммиты из svn-репо. при этом внутри гита будет обычный merge-tracking, который позволит эти svn-коммиты безболезненно накатить.
то есть теоретически ваши коллеги могут не подозревать, что вы не пользуетесь Subversion :)
я это наблюдал непосредственно в продакшене