Pull to refresh

Comments 27

в комментах можно описывать свои сложности, попробуем что-нибудь придумать
production ветки еще так же очень часто называются tags ветки… Ну по крайней мере у нас на проекте так было.
ты что-то путаешь

Тэги — это пометки конкретных версий кода, например WINDOWS-98-RELEASE.

К веткам они имеют очень опосредованное отношение.
«Тэги» в SVN — это отдельные ветки, видимо копии продакшона разных дат, в которые по договорённости никто не комитит. Иногда (не всегда, ибо ставить её относительно геморно) с защитой от комитов на уровне сервера…
не понимаю, зачем нужно вводить такое слияние

«тэги — это ветки, но в отличие от веток, в них никто не коммитит».

кроме того, они нужны для совершенно другого

у них вообще разный набор операций

это разные «типы данных»

зачем же?
хм… если папку на диске обозвать «библиотекой» она от этого не перестанет быть папкой на диске?

может я что-то путаю, но в SVN нету другого «типа данных» для тэгов. Обходятся наличием договорной ветки в структуре папок, за счёт того, что создание такой ветки — операция в SVN очень дешёвая в смысле дискового пространства.
так это проблема Svn — что у неё нет другого типа данных :)

по факту же тэг и ветка (безотносительно конкретной СКВ) — это две принципиально разные сущности

то, что в Svn — это просто файловые пути в репозитории + набор договоренностей, которые невозможно enforce — это на самом деле реальная засада! думать мешает, мешает простраивать нормальное отображение между workflow и toolflow, мешает обучать.
Дык кто сказал, что это проблема? Это бонус у них такой… ;)

А если серьёзно — при пользовании любой системы максимальные плюсы и простоту использования получаешь, вставая на точку зрения её проектировщиков, и действуя в рамках предлагаемой ими логической модели.

А смотреть с другой точки зрения — вставлять самому себе палки в колёса. Или, что вернее — ехать на поезде поперёк рельсов. Если хочешь ездить поперёк — садись на автомобиль. Хочешь вообще перпендикулярно — на вертолёт. Или на щит проходческий.

Критиковать одно средство передвижения с позиций другого получается громко, но смешно. Это я к тому, что подводить правила передвижения и обозначать проблемы в разных системах исходя с точки зрения одной из них — не получится. То, что в одной системе проблема — не проблема в другой. И наоборот. Обучать системе надо проникнувшись её собственной логикой, особенно когда она есть. Тогда проблем ни в обучении, ни в думании не будет.

Будет лишь искусственное сужение кругозора, но где без него?
если проблему назвать бонусом — от этого она не перестанет быть проблемой

поэтому дальше я комментарий читать не буду

время экономлю

зря… дальше идут слова «А если серьёзно » и то, что я писал, чтобы прочитали.
> А если серьёзно — при пользовании любой системы максимальные плюсы и простоту
> использования получаешь, вставая на точку зрения её проектировщиков, и действуя в
> рамках предлагаемой ими логической модели.

этот тезис верен только при одном дополнительном условии: «нельзя изучать альтернативы»

слава богу, в 2008 году это не так

и изучив альтернативы, мы чётко понимаем, что отсутствие выделенных понятий ветки и тэга — это проблема в Subversion

изнутри конечно оно может и не казаться проблемой

«у нас так спокон веку делают»

но при этом теряется возможность осознать, какой handicap ты на себя (возможно) навесил

Кстати, где-нибудь есть почитать, почему это является проблемой? В чём именно «handicap» использования данной логической парадигмы?
я осознал безнадёжную неадекватность Subversion только после того, как понял устройство репозитория Git

к сожалению, я не знаю ни одного текста, в котором это устройство обсуждалось бы в чистом виде, без примешивания туда вопросов workflow.

блин
отвечаю ерунду и на ерунду

у вас опять нарушение логических уровней

вы говорите про «использование» веток

я говорю про их концептуальную структуру

мой длинный тупой комментарий отзываю

эээ… Вы о чём? не понял ни про уровни, ни про коммент…

похоже, сей чат стоит замять, за непониманием друг друга.
вы говорите про «использование» веток

я говорю про их концептуальную структуру

поэтому у вас получается длинная увлекательная история про горнопроходческий щит, которая к моему тезису не имеет ни какого отношения

как невыносимо меня заколебала эта история про «в svn дешево создавать ветки»

лучше бы там стояла искусственная задержка на две минуты, чтобы не было иллюзий.
и вот ещё одно нарушение логических уровней

что значит «папка на диске».

нет такой вещи, как «папка на диске».

есть специальный inode с некоторыми флагами + формат хранения direntries

тогда этот псевдопарадокс становится хоть как-то валидным

В виндовс — есть. И в мак-ос есть. У них логика такая. И то, что можно и хард-линков понаделать — это навороты над такой логикой, которые её слегка ломают и желают непоследовательной. От того они и скрыты от рядового юзера.

И в VSS есть, и в SVN — тоже есть. Именно папки, и именно где-то «на диске» — в отдельном цельном непротиворечивом дереве, если не вылазить за пределы логики авторов.
насколько я понимаю — все ветки и прочее это как говорят — конвенции. Как договоримся так и будем. У нас все релизы лежали в tags в и имя там было — версия + дата.
всё правильно

но ведь вы туда не коммитили после создания

то есть это была не ветка
а тэг
конечно не коммитили. она была нужна только для того что бы если пользователь пишет об ошибке — взять этот таг и на нем оттестить и внести изменения если надо в транк. Мне показалось, что в production тоже не часто комитят… :) или я плохо понял статью.
А можно где-нить в начале статьи написать, под какую систему контроля версий эта статья заточена?

И непонятно, где именно недостатки и проблемы выявляются. Что именно предлагается считать недостатками и проблемами, и на каком основании?

В общем, я понял: вводит в заблуждение фраза «В этом документе описывается только анализ системы. Способы решения проблем, выявленных при анализе, будут обсуждаться отдельно.». Но в статье нет ни слова про само выявление проблем, приведена только схема для описания состояния. Возможно неплохая, но всё же — это не анализ, а подготовка информации для него.
хотя, зачатки анализа — типа обнаружение отсутствия ответственности за изменения от верстальщиков — есть, да. Но разве это анализ?
по-моему, это анализ текущего состояния системы в отношении структуры потоков изменений

естественно, ни под какую не заточена

дурацкая получилась бы статья :)

Only those users with full accounts are able to leave comments. Log in, please.