All streams
Search
Write a publication
Pull to refresh
106
0

User

Send message
>много частых мерджей станут равны по времени одному большому

Это может в вашей CVS так. в SVN это далеко не так, и наоборот рекомендуется мержится и комитится как можно чаще. Это сэкономит массу времени.

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

Правильно. Поэтому мержить надо из транка, а не в транк.

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

Даже в компании из двух человек невозможно)))

>Я боюсь себе представить, во сколько это обойдется

Глаза боятся а руки делают. Повторяю, я больше чем уверен что переход можно осуществить плавно да так что никто не заметит. Зато результат может оказаться таким что окупит все. Та же скорость комита на svn по определению выше чем в cvs. Про меркуриал я вообще молчу. Работа с ветками намного быстрее. Так что переход окупится сторицей, и чем больше вы его затягиваете тем больше денег улетает в трубу.

вы ошиблись. начиная с версии 1,5 svn хранит историю мержей
делать рефакторинг в транке? ужас…

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

Насчет CVS. Это настолько старая штука что наверняка существуют решения для быстрой конвертации репозиториев из одной системы в другую. Вместе со всей историей и тд. При этом я не вижу проблем написать подобную систему самостоятельно. Существуют различные шлюзы и враперы и тд. Переход вполне возможно сделать плавным. По крайней мере если это есть для других систем контроля то не вижу причин почему этого нет здесь. Я просто даже не думал что кто-то еще использует этот анохронизм.

И заметьте, вот вы говрите что не знакомы с SVN. Ну мне простительно мое незнакомство с CVS, ибо я не могу ковырять все допотопные системы. Но как вы можете утверждать о неизбежности проблем с переходом, даже не удосужившись в этом немного разобраться? Вы жалуетесь на проблемы с ветками, при этом даже не знаете как ветки организованны в других системах, SVN, GIT, Mercurial? Может там нет этих проблем? Может там существуют подходы, позволяющие их избежать?
Повторяю. Если мердж вызыввает такие проблемы, если появляется много конфликтов и тд. То это признак того что вы либо работатете с ним неправильно либо необходимы усилия по автоматизации процесса, либо смена системы контроля версий либо все вместе.

По поводу CVS не скажу ничего. Я с ним не работал потому что давно считаю эту систему умершей. Если вас не устраивает SVN есть еще например GIT и Mercurial. CVS позавчерашний день, и я удивлен что им еще кто-то пользуется. Не вижу ни одной причины на нем оставться, кроме лени что-то менять.
да что там svn vs cvs! Как только появился svn 1.5 тут же заставил админа её поставить, хотя на серверах центос, и в репозиториях новые версии не появляются. то есть ему бедному пришлось ручками рпмку собирать. ну ничего. справился, и в награду мы получили выигрыш во времени при мерджах, и избавились от гемороя. хотя ведь старый свн по сути все наши задачи выполнял нормально.
убунта последняя. а смысл старую испаользовать? Кодю да, под полседней верисией, а было что и под бетой кодил, это когда в нетбинсе серьезно улучшили поддержку php

и давайте не будем устраивать холивар. если есть две системы, и одна из них новее, при этом обе удовлетворяют задачам, надо переходить на более новую. я не говрю что сразу кидаться сломя голову, но по карйней мере сильно не затягивать.
моя любимая фраза, которую я часто повторяю «не доводи до фанатизма»
вы не знаете что такое художник. это не тот человек кто несмотря ни на что хочет пробовать новые феньки. я уже устал говрить что для художника главное что бы его работой были довольны. и в дедлайн он прекрасно понимает что единственный путь это сдать проект вовремя. адекватный человек не будет переписывать всеь код зная что завтра проект должен быть на продакшене и приносить бабло. и не будет вдруг в последний день проекта менять cvs на svn. Это глупо просто.

поймите художник это не синоним фанатика.
нормальный довод. глупо использовать что-то старое если есть новое. я понимаю если это новое только появилось и непонятно как будет развиваться. но svnу сто лет. cvs это архаизм.
не только svn. я например сейчас использую mercurial в одном своем проекте.
потому что cvs это позавчершний день. Глупо сейчас его использовать.
Да, ошибки менджмента. Если на обычный мердж уходит месяц извините))) Значит эта система контроля версий не подходит, либо необходима автоматизация, либо специальные люди (мантейнеры) и тд.
Во всех компаниях в которых я работал ветки внедрял я. Без меня о них даже не задумывались. Все, начиная от менджмента и заканчивая программистами о них слышали, но думали что это им или не нужно или это что-то очень сложное. После внедрения веток, большенство разработчиков их не использовали если не проследишь за этим лично, и не протрахаешь все мозги «Вася, ты ветку завел?».
А если менеджер тоже тоже таджик? А если менджер вообще не знает что такое svn?
очевидно что это не так. потому что не знаю как сейчас, но я работал будучи студентом за <100$ и то если есть работа, не ради этих самых 100 долларов, а ради того что бы научится, получить опыт. То есть фактически ради идеи, ради самого процесса. А до этого, еще раньше, я писал сам для себя всякие тетрисы, базы данных, чаты и всякую другу дребедень. Просто потому что мне было интересно. Наоборот, что бы стать профи, необходимо побыть художником.
я, если быть точнее, не то что бы мечтаю о роли техдира. Нет, я не думаю что добился всего на своем поприще. Но я думаю что это единственный шанс доказать свою правоту. Говорить можно много, понимать все очень хорошо. Даже показывать на собственном примере эффективность тех или других методологий, и подходов. Но ничего не меняется. Не меняется потому что люди видят что да, если сделать так то скорость разработки повышается, качество растет и т тд. Но им это просто не нужно. Их устраивает спокойное и размеренное движение проекта. И тебя просто загружают задачами что бы не выпендривался. Иногда доходит до прмого запрета общения с вышестоящим начальством, что бы не дай бог не сболтнул лишнего. Это уже ни раз было. Причем запрет распространяется на всех программистов. Этакая вертикаль власти. Доходит до абсурда. Начальник спускает задачу через ПМа, тот тебе её объясняет, ты указываешь на недороботки и проблемы, он соглашается, идет наверх там меняют задачу он приходит… Если бы задачи обсуждались сообща, то проблемы можно было бы выявить сразу. Но никому этого не надо. Главное что зарплату дают.
Я спокойно воспринимаю другие точки зрения. Но как я могу воспринимать токи зрения, когда они не относятся к теме моей статьи. Те кто здесь отписался, часто просто не поняли о чем я написал. Может это моя вина, может не достаточно четко выразил свою позицию, но большинство же поняли. Надо просто взглянуть на поднятую проблему под правильным углом и немножко с болльшего растояния, что бы лучше охватить. И все станет на свои места.
>не надо называть первый тип «художники»

Это всего лишь метафора. Её не надо понимать буквально.

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

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

>они вообще в другом подпространстве

может быть, но они не относятся к теме моей статьи.
к сожалению вы просто не поняли статью
я бы хотел быть техническим директором, что вполне себе достойная цель для движения по карьерной лестнице для программиста.

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Date of birth
Registered
Activity