Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
в комментах можно описывать свои сложности, попробуем что-нибудь придумать
production ветки еще так же очень часто называются tags ветки… Ну по крайней мере у нас на проекте так было.
ты что-то путаешь
Тэги — это пометки конкретных версий кода, например WINDOWS-98-RELEASE.
К веткам они имеют очень опосредованное отношение.
Тэги — это пометки конкретных версий кода, например WINDOWS-98-RELEASE.
К веткам они имеют очень опосредованное отношение.
«Тэги» в SVN — это отдельные ветки, видимо копии продакшона разных дат, в которые по договорённости никто не комитит. Иногда (не всегда, ибо ставить её относительно геморно) с защитой от комитов на уровне сервера…
не понимаю, зачем нужно вводить такое слияние
«тэги — это ветки, но в отличие от веток, в них никто не коммитит».
кроме того, они нужны для совершенно другого
у них вообще разный набор операций
это разные «типы данных»
зачем же?
«тэги — это ветки, но в отличие от веток, в них никто не коммитит».
кроме того, они нужны для совершенно другого
у них вообще разный набор операций
это разные «типы данных»
зачем же?
хм… если папку на диске обозвать «библиотекой» она от этого не перестанет быть папкой на диске?
может я что-то путаю, но в SVN нету другого «типа данных» для тэгов. Обходятся наличием договорной ветки в структуре папок, за счёт того, что создание такой ветки — операция в SVN очень дешёвая в смысле дискового пространства.
может я что-то путаю, но в SVN нету другого «типа данных» для тэгов. Обходятся наличием договорной ветки в структуре папок, за счёт того, что создание такой ветки — операция в SVN очень дешёвая в смысле дискового пространства.
так это проблема Svn — что у неё нет другого типа данных :)
по факту же тэг и ветка (безотносительно конкретной СКВ) — это две принципиально разные сущности
то, что в Svn — это просто файловые пути в репозитории + набор договоренностей, которые невозможно enforce — это на самом деле реальная засада! думать мешает, мешает простраивать нормальное отображение между workflow и toolflow, мешает обучать.
по факту же тэг и ветка (безотносительно конкретной СКВ) — это две принципиально разные сущности
то, что в Svn — это просто файловые пути в репозитории + набор договоренностей, которые невозможно enforce — это на самом деле реальная засада! думать мешает, мешает простраивать нормальное отображение между workflow и toolflow, мешает обучать.
Дык кто сказал, что это проблема? Это бонус у них такой… ;)
А если серьёзно — при пользовании любой системы максимальные плюсы и простоту использования получаешь, вставая на точку зрения её проектировщиков, и действуя в рамках предлагаемой ими логической модели.
А смотреть с другой точки зрения — вставлять самому себе палки в колёса. Или, что вернее — ехать на поезде поперёк рельсов. Если хочешь ездить поперёк — садись на автомобиль. Хочешь вообще перпендикулярно — на вертолёт. Или на щит проходческий.
Критиковать одно средство передвижения с позиций другого получается громко, но смешно. Это я к тому, что подводить правила передвижения и обозначать проблемы в разных системах исходя с точки зрения одной из них — не получится. То, что в одной системе проблема — не проблема в другой. И наоборот. Обучать системе надо проникнувшись её собственной логикой, особенно когда она есть. Тогда проблем ни в обучении, ни в думании не будет.
Будет лишь искусственное сужение кругозора, но где без него?
А если серьёзно — при пользовании любой системы максимальные плюсы и простоту использования получаешь, вставая на точку зрения её проектировщиков, и действуя в рамках предлагаемой ими логической модели.
А смотреть с другой точки зрения — вставлять самому себе палки в колёса. Или, что вернее — ехать на поезде поперёк рельсов. Если хочешь ездить поперёк — садись на автомобиль. Хочешь вообще перпендикулярно — на вертолёт. Или на щит проходческий.
Критиковать одно средство передвижения с позиций другого получается громко, но смешно. Это я к тому, что подводить правила передвижения и обозначать проблемы в разных системах исходя с точки зрения одной из них — не получится. То, что в одной системе проблема — не проблема в другой. И наоборот. Обучать системе надо проникнувшись её собственной логикой, особенно когда она есть. Тогда проблем ни в обучении, ни в думании не будет.
Будет лишь искусственное сужение кругозора, но где без него?
если проблему назвать бонусом — от этого она не перестанет быть проблемой
поэтому дальше я комментарий читать не буду
время экономлю
поэтому дальше я комментарий читать не буду
время экономлю
> А если серьёзно — при пользовании любой системы максимальные плюсы и простоту
> использования получаешь, вставая на точку зрения её проектировщиков, и действуя в
> рамках предлагаемой ими логической модели.
этот тезис верен только при одном дополнительном условии: «нельзя изучать альтернативы»
слава богу, в 2008 году это не так
и изучив альтернативы, мы чётко понимаем, что отсутствие выделенных понятий ветки и тэга — это проблема в Subversion
изнутри конечно оно может и не казаться проблемой
«у нас так спокон веку делают»
но при этом теряется возможность осознать, какой handicap ты на себя (возможно) навесил
> использования получаешь, вставая на точку зрения её проектировщиков, и действуя в
> рамках предлагаемой ими логической модели.
этот тезис верен только при одном дополнительном условии: «нельзя изучать альтернативы»
слава богу, в 2008 году это не так
и изучив альтернативы, мы чётко понимаем, что отсутствие выделенных понятий ветки и тэга — это проблема в Subversion
изнутри конечно оно может и не казаться проблемой
«у нас так спокон веку делают»
но при этом теряется возможность осознать, какой handicap ты на себя (возможно) навесил
блин
отвечаю ерунду и на ерунду
у вас опять нарушение логических уровней
вы говорите про «использование» веток
я говорю про их концептуальную структуру
мой длинный тупой комментарий отзываю
отвечаю ерунду и на ерунду
у вас опять нарушение логических уровней
вы говорите про «использование» веток
я говорю про их концептуальную структуру
мой длинный тупой комментарий отзываю
как невыносимо меня заколебала эта история про «в svn дешево создавать ветки»
лучше бы там стояла искусственная задержка на две минуты, чтобы не было иллюзий.
лучше бы там стояла искусственная задержка на две минуты, чтобы не было иллюзий.
и вот ещё одно нарушение логических уровней
что значит «папка на диске».
нет такой вещи, как «папка на диске».
есть специальный inode с некоторыми флагами + формат хранения direntries
тогда этот псевдопарадокс становится хоть как-то валидным
что значит «папка на диске».
нет такой вещи, как «папка на диске».
есть специальный inode с некоторыми флагами + формат хранения direntries
тогда этот псевдопарадокс становится хоть как-то валидным
В виндовс — есть. И в мак-ос есть. У них логика такая. И то, что можно и хард-линков понаделать — это навороты над такой логикой, которые её слегка ломают и желают непоследовательной. От того они и скрыты от рядового юзера.
И в VSS есть, и в SVN — тоже есть. Именно папки, и именно где-то «на диске» — в отдельном цельном непротиворечивом дереве, если не вылазить за пределы логики авторов.
И в VSS есть, и в SVN — тоже есть. Именно папки, и именно где-то «на диске» — в отдельном цельном непротиворечивом дереве, если не вылазить за пределы логики авторов.
насколько я понимаю — все ветки и прочее это как говорят — конвенции. Как договоримся так и будем. У нас все релизы лежали в tags в и имя там было — версия + дата.
А можно где-нить в начале статьи написать, под какую систему контроля версий эта статья заточена?
И непонятно, где именно недостатки и проблемы выявляются. Что именно предлагается считать недостатками и проблемами, и на каком основании?
В общем, я понял: вводит в заблуждение фраза «В этом документе описывается только анализ системы. Способы решения проблем, выявленных при анализе, будут обсуждаться отдельно.». Но в статье нет ни слова про само выявление проблем, приведена только схема для описания состояния. Возможно неплохая, но всё же — это не анализ, а подготовка информации для него.
И непонятно, где именно недостатки и проблемы выявляются. Что именно предлагается считать недостатками и проблемами, и на каком основании?
В общем, я понял: вводит в заблуждение фраза «В этом документе описывается только анализ системы. Способы решения проблем, выявленных при анализе, будут обсуждаться отдельно.». Но в статье нет ни слова про само выявление проблем, приведена только схема для описания состояния. Возможно неплохая, но всё же — это не анализ, а подготовка информации для него.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Аудит системы контроля версий, ч. I