Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 168
git наше всё.
а за статью спасибо!
а за статью спасибо!
Надо ввести законопроект, запрещующий разжигание холиваров по VCS-признаку.
Любой топик про SVN/Mercurial/Bazaar и т.д. и найдется кто-нибудь, доказывающий с пеной у рта, что git круче и во сколько раз.
Любой топик про SVN/Mercurial/Bazaar и т.д. и найдется кто-нибудь, доказывающий с пеной у рта, что git круче и во сколько раз.
Так все просто — гит сейчас очень популярен и на слуху, и, зачастую, многие даже и не знают что есть какие-либо альтернативы.
И хоть я долгое время работал меркуриалом, я тоже за гит — популярность, опять же, сказывается.
И хоть я долгое время работал меркуриалом, я тоже за гит — популярность, опять же, сказывается.
Да я и не планировал разводить никаких холиваров :) Я просто высказал свое мнения. Как раз сейчас на работе мы используем меркуриал.
Думаю в основном инерция — та же причина, почему до сих пор не вымер древний CVS или богомерзкий VSS. Плюс еще и неосведомленность.
в svn очень интенсивно используется svn:externals, эквивалентной замены которому в dvcs нет (я знаю про sub-modules и subrepos). Переход на другую систему контроля версий требует пересмотра архитектуры и/или иной организации кода. Это достаточно дорого для бизнес.
Я чем вас не устраивает subrepos в качестве замены svn:externals?
Да этот холивар уже 100 раз поднимался. svn:externals втыкается зачастую бессистемно, в разные места проекта, потому что при апдейте это все автоматически обрабатывается. А когда переезжаешь на git/hg вся эта автоматика перестает работать. Нужно ходить руками обновлять каждую субрепу. И это очень раздражающая рутина, а так же постоянный источник неявных ошибок. Поэтому надо или код реорганизовывать, или оставаться на svn.
> при апдейте это все автоматически обрабатывается. А когда переезжаешь на git/hg вся эта автоматика перестает работать.
Как говорится, «УМВР. ЧЯДНТ?»
Как говорится, «УМВР. ЧЯДНТ?»
Или один раз написать скрипт.
решений много, но все они имеют те или иные недостатки. Git over Svn, например. В конечном итоге, решение о переходе с svn на другую систему контроля версий требует учета многих факторов, в том числе специфичных для каждого конкретного проекта. Часто оказывается так, что для бизнеса выгоднее продолжать использовать старое проверенное решение.
вот, кстати, тред ниже как раз о том, что я говорил.
а зачем?
Если для бизнеса не нужна децентрализованная система контроля, бизнес предпочтёт использовать проверенный вариант.
Если для бизнеса не нужна децентрализованная система контроля, бизнес предпочтёт использовать проверенный вариант.
Так DVCS позволяет организовать тот-же workflow что и при централизированных, но плюс еще много. Хотите — делайте push всем изменениям на центральны сервер как раньше, но зато можно внутри группы или у себя на компьютере — организовать работу более гибко и удобно. Плюс можно работать удаленно или в командировке, не завися от интернета, VPN-а и центрального сервера. Плюс надежность — когда у каждого разработчика полная копия репозитория: восстановление упавшего VCS сервера парализует всю работу, а отсутствие своевременного бекапа — может стать глобальной катастрофой стоящей жизни фирме или проекту. В одной фирме, где я работал таки в какой-то момент выяснили, что благодаря распи*дяйству сисадмина, SVN репозиторий пол года не бекапился. Если бы он навернулся, то стартап можно было бы спокойно закрывать.
В том-то и дело, что этот workflow приходится организовывать, административными методами, чуть ли не под угрозой штрафов. Запушил верстальщик бэкендеру новый шаблон и ждёт своих денег, а никто и не в курсе об этом…
читайте внимательно, зачем мне давать разработчику лишние варианты?
Есть workflow, который не подразумевает обмена кода мимо репозитория, ваши «гибкие» и «удобные» варианты — это ваше имхо.
Проблема бэкапа — это проблема не системы контроля версий, вообще не понятно зачем вы сюда её приплели.
Есть workflow, который не подразумевает обмена кода мимо репозитория, ваши «гибкие» и «удобные» варианты — это ваше имхо.
Проблема бэкапа — это проблема не системы контроля версий, вообще не понятно зачем вы сюда её приплели.
Ну если вы относитесь к разработчикам, как маленьким детям, которых нужно держать за ручку и кормить с ложечки — о могу только посочувствовать тем, кому приходится с вами работать. Микроменеджмент — это очень плохо, а ваши ограничения, девелоперы все равно найдут способ обойти.
им не нужно ничего придумывать и обходить, за них уже эту задачу решили.
И с чего вы решили, что у них есть подобные потребности?
Мы регулярно обсуждаем желания людей, но кроме как идей «а давайте попробуем!», никто внятного workflow не предложил.
И с чего вы решили, что у них есть подобные потребности?
Мы регулярно обсуждаем желания людей, но кроме как идей «а давайте попробуем!», никто внятного workflow не предложил.
Речь не идёт об изменении workflow, вообще-то.
Внятные workflow описаны в книгах вроде Pro Git. А слишком много решать за работников вредно. Они могут не понять и в один прекрасный день молча положить заявление на стол.
Мы регулярно обсуждаем желания людей, но кроме как идей «а давайте попробуем!», никто внятного workflow не предложил.
Я даже на секунду подумал, что может быть с вашими людьми что-то не так, но у меня достаточный багаж таких вот обсуждений и предложений.
Тут собственно конфликт интересов — с одной стороны менеджмент все устраивает поэтому любые предложения воспринимаются вяло и «ну… мы подумаем» (следует читать как «я сейчас тебе не хочу говорить о том, что мне не нравится твоя идея, так что отвечу тебе лично через неделю когда ты придешь ко мне и спросишь „как там“, ну или забудешь).
С другой стороны разработчики, которые живут в своем, параллельном мире и им, зачастую хочется работать так, что бы оставаться актуальными на рынке труда (сотрудники, по крайней мере в ИТ, сидят не на привязи. И если им что-то не понравится, то свалить на другое, более вкусное местечко они могут и за неделю неспешных поисков — такова реальность*). Пошла повальная мода на XXX, то есть вероятность что на одном из таких вот обсуждений они начнут говорить о том, что хочется все таки заюзать ХХХ, даже толком еще не зная куда ее можно прикурить. А могут и начать что-то дельное советовать, но будете ли готовы вы.
И, кстати, еще такой вопрос, на который попробуйте, пожалуйста, ответить честно — а насколько вы действительно готовы что либо менять?
* есть отдельная категория людей которые никуда и никогда не сбегут (не будем говорить о тех, кто в доле) — это такие паразиты, которым плевать что делать, как делать и когда делать. Они как копались в своем говне, так и будут еще 10 лет копаться. Толку от них мало, но зато стабильно.
Я даже на секунду подумал, что может быть с вашими людьми что-то не так, но у меня достаточный багаж таких вот обсуждений и предложений.
Тут собственно конфликт интересов — с одной стороны менеджмент все устраивает поэтому любые предложения воспринимаются вяло и «ну… мы подумаем» (следует читать как «я сейчас тебе не хочу говорить о том, что мне не нравится твоя идея, так что отвечу тебе лично через неделю когда ты придешь ко мне и спросишь „как там“, ну или забудешь).
С другой стороны разработчики, которые живут в своем, параллельном мире и им, зачастую хочется работать так, что бы оставаться актуальными на рынке труда (сотрудники, по крайней мере в ИТ, сидят не на привязи. И если им что-то не понравится, то свалить на другое, более вкусное местечко они могут и за неделю неспешных поисков — такова реальность*). Пошла повальная мода на XXX, то есть вероятность что на одном из таких вот обсуждений они начнут говорить о том, что хочется все таки заюзать ХХХ, даже толком еще не зная куда ее можно прикурить. А могут и начать что-то дельное советовать, но будете ли готовы вы.
И, кстати, еще такой вопрос, на который попробуйте, пожалуйста, ответить честно — а насколько вы действительно готовы что либо менять?
* есть отдельная категория людей которые никуда и никогда не сбегут (не будем говорить о тех, кто в доле) — это такие паразиты, которым плевать что делать, как делать и когда делать. Они как копались в своем говне, так и будут еще 10 лет копаться. Толку от них мало, но зато стабильно.
Мы готовы поменять, когда процент людей желающих перемен приблизится хотя бы к 30-50% + будет экспертная оценка, что да, реально есть смысл использовать эту технологию.
Сейчас ситуация такая на 10 человек 1.5 хотят переход на git/hg, остальных svn утраивает.
А у меня сразу первые мысли про $:
1) обучение людей.
2) перенастройка настройка серверов (хранилище, билд сервер, система тасков, настройка экспорта сорцов в хранилище клиента и т.д.)
Уважаемый, вы бы по аккуратнее в выражениях «Они как копались в своем говне, так и будут еще 10 лет копаться. Толку от них мало, но зато стабильно.», «и за неделю неспешных поисков — такова реальность*»
Ваш детский бред выдают только ваши необоснованный амбиции и непонимание сути дела.
Сейчас ситуация такая на 10 человек 1.5 хотят переход на git/hg, остальных svn утраивает.
А у меня сразу первые мысли про $:
1) обучение людей.
2) перенастройка настройка серверов (хранилище, билд сервер, система тасков, настройка экспорта сорцов в хранилище клиента и т.д.)
Уважаемый, вы бы по аккуратнее в выражениях «Они как копались в своем говне, так и будут еще 10 лет копаться. Толку от них мало, но зато стабильно.», «и за неделю неспешных поисков — такова реальность*»
Ваш детский бред выдают только ваши необоснованный амбиции и непонимание сути дела.
будет экспертная оценка
И кто будет выступать в роли эксперта? Мне, относительно недавно, один приглашенный «эксперт» (видимо люди скупились на его 15+ лет стажа), с умным видом втирал то, я вообще ничего не понимаю в архитектуре, после того, как я ему рассказал как был устроен наш игровой сервер и как я хотел это все адаптировать под достаточно быстро растущие нагрузки (>10к сессий одновременно на 2-3 серверах). В итоге, оказывается, надо было вместо монги начать использовать оракл (постгрес используют только лузеры для домашних сайтов — почти дословно), а все эти носкули это новомодные веяния которые через пару лет сойдут на нет. А после бреда про то, что надо было из 20-30 табличек выбирать данные одним запросом (каким-то магическим способом в оракле решили проблему что при этом у нас будет выборка на пару сотен столбцов и 100500 записей большинство из которых будет в null и скорость этого всего будет в сотню раз меньше), наш разговор решили прервать…
Кстати, час этого эксперта стоит как обычный, восьмичасовой рабочий день обычного программиста. Но тут даже проблема не в этом, проблема в том, что многие экспертные оценки делаются на «текущий момент ясной головой эксперта», а вот разработчикам дальше с этим приходиться жить.
А у меня сразу первые мысли про $
Так это правильно, но к тем двум пунктам, которые вы описали, надо бы добавить третий — сравнение с тем, что есть на данный момент. Иногда бывает что гораздо выгоднее переобучить людей и все перенастроить, нежели и дальше отнимать какой-то процент рабочего времени на борьбу с текущей системой
Ваш детский бред выдают только ваши необоснованный амбиции и непонимание сути дела.
Вот скажите, что вы можете предложить действительно хорошему разработчику что бы он остался в компании, скажем… на 5 лет? Судя по вашим комментариям (может в реальной жизни все по другому) — то мало чего.
И кто будет выступать в роли эксперта? Мне, относительно недавно, один приглашенный «эксперт» (видимо люди скупились на его 15+ лет стажа), с умным видом втирал то, я вообще ничего не понимаю в архитектуре, после того, как я ему рассказал как был устроен наш игровой сервер и как я хотел это все адаптировать под достаточно быстро растущие нагрузки (>10к сессий одновременно на 2-3 серверах). В итоге, оказывается, надо было вместо монги начать использовать оракл (постгрес используют только лузеры для домашних сайтов — почти дословно), а все эти носкули это новомодные веяния которые через пару лет сойдут на нет. А после бреда про то, что надо было из 20-30 табличек выбирать данные одним запросом (каким-то магическим способом в оракле решили проблему что при этом у нас будет выборка на пару сотен столбцов и 100500 записей большинство из которых будет в null и скорость этого всего будет в сотню раз меньше), наш разговор решили прервать…
Кстати, час этого эксперта стоит как обычный, восьмичасовой рабочий день обычного программиста. Но тут даже проблема не в этом, проблема в том, что многие экспертные оценки делаются на «текущий момент ясной головой эксперта», а вот разработчикам дальше с этим приходиться жить.
А у меня сразу первые мысли про $
Так это правильно, но к тем двум пунктам, которые вы описали, надо бы добавить третий — сравнение с тем, что есть на данный момент. Иногда бывает что гораздо выгоднее переобучить людей и все перенастроить, нежели и дальше отнимать какой-то процент рабочего времени на борьбу с текущей системой
Ваш детский бред выдают только ваши необоснованный амбиции и непонимание сути дела.
Вот скажите, что вы можете предложить действительно хорошему разработчику что бы он остался в компании, скажем… на 5 лет? Судя по вашим комментариям (может в реальной жизни все по другому) — то мало чего.
1) Если вы пригласили эксперта не специализирующегося на игровых серверах, кто виноват?
2) ещё раз. с текущей системой хранения кода никто не борется.
3) долю в компании и интересные проекты.
Если человек перерос компанию и её проекты, я сам скажу ему об этом и пусть он думаю, как ему поступать дальше. Какой мне смысл «травить» человека, неинтересной работой? На лицо сразу падание производительности, морального настроя, командного духа в коллективе и т.д.
Ещё раз не стоит рассуждать о всей отросли со своей колокольни. Мне сейчас в проекте нужно собрать 200 форм отчётом для системы для крупного холдинга, и вот зачем мне брать «действительно хорошего программиста» на эту задачу? Он от меня сбежит через 2 недели, максимум месяц. И я несу расходы.
На часть задач, не нужны амбициозные люди, и пока вы этой не поймёте, вы будет терять $ необоснованно переходя на новые фреймворки, технологии и т.д.!
2) ещё раз. с текущей системой хранения кода никто не борется.
3) долю в компании и интересные проекты.
Если человек перерос компанию и её проекты, я сам скажу ему об этом и пусть он думаю, как ему поступать дальше. Какой мне смысл «травить» человека, неинтересной работой? На лицо сразу падание производительности, морального настроя, командного духа в коллективе и т.д.
Ещё раз не стоит рассуждать о всей отросли со своей колокольни. Мне сейчас в проекте нужно собрать 200 форм отчётом для системы для крупного холдинга, и вот зачем мне брать «действительно хорошего программиста» на эту задачу? Он от меня сбежит через 2 недели, максимум месяц. И я несу расходы.
На часть задач, не нужны амбициозные люди, и пока вы этой не поймёте, вы будет терять $ необоснованно переходя на новые фреймворки, технологии и т.д.!
Эксперта приглашал не я, этот разговор с ним состоялся случайно — он высказал бред (что-то вроде ява — это энерпрайз онли и ничего больше), я зацепился, ну а дальше мы услышали много интересного в адрес всего, что не связано с ораклом.
На часть задач, не нужны амбициозные люди, и пока вы этой не поймёте, вы будет терять $ необоснованно переходя на новые фреймворки, технологии и т.д.!
Собственно с этого и надо было начинать. Хорошо, что вы понимаете, что вам разработчик, который привык находится «на волне» технологий не нужен — от него только проблемы, а нужен как раз таки тот, которого я и описал — ему на прошлых месте вдолбили технологии A, B и С — так он и будет их использовать. Может прочитает еще про D, подумает — а круто было бы использовать, придет, пообщается с вами и с другими разработчиками (а они то про D не читали) — разочаруется и вернется опять к своей привычной C.
А по поводу траты денег — категорически не согласен. Сейчас, при использовании новомодных решений можно очень хорошо сэкономить. Если раньше многие вещи делались командами из 5-7 человек по 3-4 месяца, то сейчас они делаются за 1-2 месяца командой из трех человек, а всего то A 1.0 сменили на A 3.0 которая на A 1.0 похожа только названием.
На часть задач, не нужны амбициозные люди, и пока вы этой не поймёте, вы будет терять $ необоснованно переходя на новые фреймворки, технологии и т.д.!
Собственно с этого и надо было начинать. Хорошо, что вы понимаете, что вам разработчик, который привык находится «на волне» технологий не нужен — от него только проблемы, а нужен как раз таки тот, которого я и описал — ему на прошлых месте вдолбили технологии A, B и С — так он и будет их использовать. Может прочитает еще про D, подумает — а круто было бы использовать, придет, пообщается с вами и с другими разработчиками (а они то про D не читали) — разочаруется и вернется опять к своей привычной C.
А по поводу траты денег — категорически не согласен. Сейчас, при использовании новомодных решений можно очень хорошо сэкономить. Если раньше многие вещи делались командами из 5-7 человек по 3-4 месяца, то сейчас они делаются за 1-2 месяца командой из трех человек, а всего то A 1.0 сменили на A 3.0 которая на A 1.0 похожа только названием.
У нас есть в команде люди, кто читает про новые инструменты, типа D, но их меньшинство, и они понимают, что такое просчёт в выборе технологии для бизнеса.
Представьте себе ситуацию:
Международный холдинг. Клиенты по всему миру. PM, прочитав в сети про одно «модное» опенсурс решение, предлагает его использовать, для повышения скорости работы программного комплекса в разы. Эту идею подхватывают сейлзы по всему миру, и делают предпродажи на сотни тыс евро нашей системы. В это время начинается разработка. Когда разработка вроде бы завершена, проводится нагрузочное тестирование и оказывается, что опенсурс решение не держит нагрузку ) Ну никак. И начинаются адские месяцы общение с комьюните, тюнинг конфигов и ковыряние сорцов. А клиенты уже висят на ушах. Ну и т.д.
Дальше, про новые технологии нет смысл общаться внутри коллектива, нужно сразу идти туда где их использовали, благо интернет ни для кого не закрыт. Общаться с людьми у кого год и больше опыта использования технологии D именно в коммерческой разработке, желательно схожего с нами направления.
И тогда уже стоит пробовать внедрять в небольших проектах, и то если есть какие-то неоспоримые преимущества.
«новомодных решений можно очень хорошо сэкономить» — если вы стартап и вам очень важно время выката решений, то пожалуй соглашусь.
Если делаете по для ядерных реакторов, то сами понимаете ;)
Представьте себе ситуацию:
Международный холдинг. Клиенты по всему миру. PM, прочитав в сети про одно «модное» опенсурс решение, предлагает его использовать, для повышения скорости работы программного комплекса в разы. Эту идею подхватывают сейлзы по всему миру, и делают предпродажи на сотни тыс евро нашей системы. В это время начинается разработка. Когда разработка вроде бы завершена, проводится нагрузочное тестирование и оказывается, что опенсурс решение не держит нагрузку ) Ну никак. И начинаются адские месяцы общение с комьюните, тюнинг конфигов и ковыряние сорцов. А клиенты уже висят на ушах. Ну и т.д.
Дальше, про новые технологии нет смысл общаться внутри коллектива, нужно сразу идти туда где их использовали, благо интернет ни для кого не закрыт. Общаться с людьми у кого год и больше опыта использования технологии D именно в коммерческой разработке, желательно схожего с нами направления.
И тогда уже стоит пробовать внедрять в небольших проектах, и то если есть какие-то неоспоримые преимущества.
«новомодных решений можно очень хорошо сэкономить» — если вы стартап и вам очень важно время выката решений, то пожалуй соглашусь.
Если делаете по для ядерных реакторов, то сами понимаете ;)
PM, прочитав в сети про одно «модное» опенсурс решение, предлагает его использовать, для повышения скорости работы программного комплекса в разы.
Обычно в такой ситуации следует сразу хвататься за голову и грубой силой убедить РМ-а в том, что он не совсем прав. Слишком уж далеко от правды. Обычно даже после недолгого ознакомления будет видно за счет чего это «в разы» было получено. А там уже должен включится отдел мозга отвечающий за адекватность. Иногда юз-кейс как раз именно тот что нужен (допустим жертвуем консистентностью в угоду производительности).
К примеру взять тот же гит. У нас как было, фич новых много, одна ветка — все туда, что не успели в комментарии или стабами закрыли и на продакшн. Впринципе оверхед по работе с dvcs минимален, но перед релизом тратили достаточно времени что бы закрыть все недоделанные фичи и все равно в продакшн летети баги связанные с еще недопиленным функционалом.
Потратили немного времени на то, что бы каждую фичу в своей ветке делать, а потом уже собирать билды — оверхед увеличился, но общее количество времени и нервов отнимаемое на релизы и борьбу с мефическими багами в целом по компании снизилось, значительно (лично мое — до 20% т.е. весь следующий день после релиза я не переключался на то, что бы объяснить всем остальным кто где накосячил, что это уже исправлено — фича допилена и работает как надо, но надо потратить еще немного времени для того, что бы исправить в продакшн версии).
При использовании svn-а все то время, что мне удалось сохранить я бы тратил на то, что бы это все нормально смержить (пробовал мержить треть проекта с кучей перемещений файлов).
Обычно в такой ситуации следует сразу хвататься за голову и грубой силой убедить РМ-а в том, что он не совсем прав. Слишком уж далеко от правды. Обычно даже после недолгого ознакомления будет видно за счет чего это «в разы» было получено. А там уже должен включится отдел мозга отвечающий за адекватность. Иногда юз-кейс как раз именно тот что нужен (допустим жертвуем консистентностью в угоду производительности).
К примеру взять тот же гит. У нас как было, фич новых много, одна ветка — все туда, что не успели в комментарии или стабами закрыли и на продакшн. Впринципе оверхед по работе с dvcs минимален, но перед релизом тратили достаточно времени что бы закрыть все недоделанные фичи и все равно в продакшн летети баги связанные с еще недопиленным функционалом.
Потратили немного времени на то, что бы каждую фичу в своей ветке делать, а потом уже собирать билды — оверхед увеличился, но общее количество времени и нервов отнимаемое на релизы и борьбу с мефическими багами в целом по компании снизилось, значительно (лично мое — до 20% т.е. весь следующий день после релиза я не переключался на то, что бы объяснить всем остальным кто где накосячил, что это уже исправлено — фича допилена и работает как надо, но надо потратить еще немного времени для того, что бы исправить в продакшн версии).
При использовании svn-а все то время, что мне удалось сохранить я бы тратил на то, что бы это все нормально смержить (пробовал мержить треть проекта с кучей перемещений файлов).
Как-то вы политкорректно выразились :) PM вообще не должен быть инициатором введения товой технологии в идеяле. А уж тем более бежать впереди паровоза и собюирать заказы если ещё не проведено тестирование. А уж про то, что начинать нужно с планирования и вопрос производительности не должен возникать в конце разработке — так это мне казалось должно быть для всех очевидно.
Эту идею подхватывают сейлзы по всему миру, и делают предпродажи на сотни тыс евро нашей системы. В это время начинается разработка.
Я сейчас не понял — вы сначала продаете, а потом разрабатываете что ли? Крутые парни…
Я сейчас не понял — вы сначала продаете, а потом разрабатываете что ли? Крутые парни…
В итоге, оказывается, надо было вместо монги начать использовать оракл (постгрес используют только лузеры для домашних сайтов — почти дословно), а все эти носкули это новомодные веяния которые через пару лет сойдут на нет. А после бреда про то, что надо было из 20-30 табличек выбирать данные одним запросом (каким-то магическим способом в оракле решили проблему что при этом у нас будет выборка на пару сотен столбцов и 100500 записей большинство из которых будет в null и скорость этого всего будет в сотню раз меньше), наш разговор решили прервать…вау. Он вобщет прописные истины говорил. В оракле нет магии, там тысячи человеколет оптимизации.
А можно пожалуйста чуточку подробнее о тамошник оптимизациях. Суть задачи — достать полностью профиль пользователя который разбит на более чем 20 таблиц (10-20 колонок, в основном инты), в каждой из которых миллионы или десятки силлионов записей. Отношения один ко могим, например юзер имеет несколько объектов на карте к которым привязано еще куча других объектов. Собственно одним запросом то достать можно, но что нам при этом вернется? Около 300 колонок и тысяч десять рядов. При этом большая часть это null-ы. Не припомню во сколько трафика мне это выливалось, но хибернет при маппинге этого ввего отжирал разом более 200 метров мапил в течении нескольких секунд.
На сравние в монге все профили хранились в одной коллекции, средний вес объекта не дотягивал и до полутора мб, сохранялось-доставалось все атомарно (одна запись же вытаскивается) и за несколько миллисекунд.
На сравние в монге все профили хранились в одной коллекции, средний вес объекта не дотягивал и до полутора мб, сохранялось-доставалось все атомарно (одна запись же вытаскивается) и за несколько миллисекунд.
надо было спросить у консультанта обоснование того что он предлагал. Скорей всего он бы сделал тест и показал конкретные цифры. Про хибернейт бы объяснил.
А так можно сюда
http://www.sql.ru/forum/actualtopics.aspx?bid=58
А так можно сюда
http://www.sql.ru/forum/actualtopics.aspx?bid=58
надо было спросить у консультанта обоснование того что он предлагал. Скорей всего он бы сделал тест и показал конкретные цифры. Про хибернейт бы объяснил.
Обоснование — это оракл, там все быстро
А так можно сюда
Зачем?
Но вообще мне кажется вы даже и не читали то, что я написал. Я вам еще раз повторяю, что одним запросом это быстро не вытащишь. Это нереально. Потому что данные находятся в трех разных местах. Это такой вид бд — реляционная.
У меня за время работы накопилось много минусов в сторону РСУБД, зачастую их используют только потому, что нормальных альтернатив, до недавнего времени не было вообще. Да и любой разработчик знает как работать с рсубд.
При использовании носкуля (в моем случае монги), я весь этот профиль пользователя вообще бы хранил в одном сериализованном массиве со всеми его связями — одна запись сохраняется и загружается, атомарно. Тут надо уже изменять законы физики, что бы такой вариант работал медленнее, нежели рсубд.
Обоснование — это оракл, там все быстро
А так можно сюда
Зачем?
Но вообще мне кажется вы даже и не читали то, что я написал. Я вам еще раз повторяю, что одним запросом это быстро не вытащишь. Это нереально. Потому что данные находятся в трех разных местах. Это такой вид бд — реляционная.
У меня за время работы накопилось много минусов в сторону РСУБД, зачастую их используют только потому, что нормальных альтернатив, до недавнего времени не было вообще. Да и любой разработчик знает как работать с рсубд.
При использовании носкуля (в моем случае монги), я весь этот профиль пользователя вообще бы хранил в одном сериализованном массиве со всеми его связями — одна запись сохраняется и загружается, атомарно. Тут надо уже изменять законы физики, что бы такой вариант работал медленнее, нежели рсубд.
если консультант не может обосновать свои консультации то зачем вы его наняли? Это ж не детский сад, это работа за деньги.
Создаётся структура под задачу, наполняется тестовыми рандомными данными, прогоняются тестовые запросы, делаются выводы. Это обычная практика.
По поводу сравнения ноСКЛ с реляционными БД — я не вижу смысла объяснять прописные истины. Их точно также можно сравнить в конкретной задаче (вашей) и даже на конкретных (ваших) данных. Конечно для этого нужно нанять ораклового консультанта за деньги но тут уж ничего не поделать.
Создаётся структура под задачу, наполняется тестовыми рандомными данными, прогоняются тестовые запросы, делаются выводы. Это обычная практика.
По поводу сравнения ноСКЛ с реляционными БД — я не вижу смысла объяснять прописные истины. Их точно также можно сравнить в конкретной задаче (вашей) и даже на конкретных (ваших) данных. Конечно для этого нужно нанять ораклового консультанта за деньги но тут уж ничего не поделать.
3,14#%€ц, Вы вообще читали мои комментарии? Я уже вроде два раза упомянул, что публичный разговор с данным консультантом состоялся случайно.
конечно читал. И на практике часто такое встречал. Начальство нанимает консультанта от решения которого могут повлиять на оценку работы программистов. Программисты обычно очень этим недовольны. Такова жизнь.
Потому что, я уже говорил — решения консультантом принимаются на основе некоего среза данных, Не учитывая много скрытых, на первый взгляд, особенностей. Программистам потом с этим жить. И доказать то, что консультант в чем-то был не прав — практически реально.
Цели для которых был приглашен данный эксперт мне, да и всем, кто там был, не совсем ясны — новый продукт, новая группа разработки. Насколько я знаю, от его услуг отказались, потому что по сути люди заплатили кучу денег за рекламу оракла как серебрянную пулю
Цели для которых был приглашен данный эксперт мне, да и всем, кто там был, не совсем ясны — новый продукт, новая группа разработки. Насколько я знаю, от его услуг отказались, потому что по сути люди заплатили кучу денег за рекламу оракла как серебрянную пулю
То есть бизнес не планирует расти? Плохой бизнес.
У централизованной системы контроля версий есть свои плюсы: уменьшенный размер чекаута и быстрое (непосредственное) портирование изменений в главный репозиторий.
Там, где важны эти преимущества и используется svn, например.
Там, где важны эти преимущества и используется svn, например.
Меня в Mercurial привлекают другие фичи. А «централизацию» приходится эмулировать через административные (в смысле бумажные, под подпись) инструкции.
SVN — бесплатное решение.
есть много бесплатного хостинга SVN, пригодного не только для opensource решений.
для Git бесплатного облачного хостинга с ограничением доступа я не нашел :-(
есть много бесплатного хостинга SVN, пригодного не только для opensource решений.
для Git бесплатного облачного хостинга с ограничением доступа я не нашел :-(
bitbacket?
Bitbucket.org — неограниченное количество hg/git репозиториев с неограниченным местом. Управление правами (read/write/admin). Платно — большое количество таких пользователей. Вроде до 5 бесплатно.
когда я искал хостинг несколько лет назад — не наткнулся, спасибо, буду иметь в виду
— желательно коммиты и патчи делать логически завершёнными;
Патчи — может быть, а коммиты то зачем? Вся прелесть распределенных систем, что в своем репозитории можно делать сколько угодно коммитов, не боясь что-нибудь кому-нибудь испортить, и только потом делать push. Это как раз основная претензия к SVN — создавать ветки на каждый чих а потом их мержить слишком геморройно, а не делать коммит в течении дня-двух-недели, пока не добил полностью какой-нибудь «фичер» — это глупо и опасно, и нафига тогда нужна СКВ если она не позволяет удобно сохранять изменения и откатывать их с любой удобной мне резолюцией.
Патчи — может быть, а коммиты то зачем? Вся прелесть распределенных систем, что в своем репозитории можно делать сколько угодно коммитов, не боясь что-нибудь кому-нибудь испортить, и только потом делать push. Это как раз основная претензия к SVN — создавать ветки на каждый чих а потом их мержить слишком геморройно, а не делать коммит в течении дня-двух-недели, пока не добил полностью какой-нибудь «фичер» — это глупо и опасно, и нафига тогда нужна СКВ если она не позволяет удобно сохранять изменения и откатывать их с любой удобной мне резолюцией.
habrahabr.ru/post/140496/#comment_4695516 промахнулся
В конце концов подавляющая часть патчей становится коммитами, да и написано там «желательно», а почему желательно, написано на пару пунктов выше. Представьте ситуацию, вы на новом месте работы, вам выдали репозиторий в 2000 коммитов, треть из них незаконченные и программу надо доработать/исправить. Вы достаёте рабочую копию ревизии и неожиданно замечаете, что она не просто не работает, а даже не собирается. Что вы подумаете в этот момент?
По-моему опыту «достать произвольную версию из середины» — это очень редкий сценарий, и случается он когда нужно или отследить изменения или откатиться. Для обоих, чем выше резолюция изменений — тем лучше. Во всех остальных случаях, работают не с отдельными версиями — а с бранчами, метками и «головами».
Я честно не понимаю, зачем экономить на коммитах — по моему это противоречит самой идеи и назначению СКВ.
Я честно не понимаю, зачем экономить на коммитах — по моему это противоречит самой идеи и назначению СКВ.
Почему обязательно из середины? Эта треть может быть самой свежей.
А вот экономить коммиты я как раз и не предлагал. Размер не нужно раздувать. Коммиты — это как рефакторинг, изменения по чуть-чуть. Но если они логически завершены, то проще воспринимаются и с ними легче работать/разбирать. А если они не закончены, то какой смысл их сохранять?
А вот экономить коммиты я как раз и не предлагал. Размер не нужно раздувать. Коммиты — это как рефакторинг, изменения по чуть-чуть. Но если они логически завершены, то проще воспринимаются и с ними легче работать/разбирать. А если они не закончены, то какой смысл их сохранять?
workflow может быть такой, что без коммита даже синтаксис толком не проверить.
Логически — конечно, но требовать готовый оттестированый фичер, как условие для коммита — ИМХО, это слишком.
на этот случай в git есть rebase, с помощью которого можно объединить какие угодно коммиты, тем самым сделав их логически завершёнными. Это можно сделать, например, перед push'ем в центральный репозиторий.
Засоряют лишние коммиты историю. Что меня бесит иной раз: куча коммитов, один на сотню строк, а потом пяток-другой исправление опечаток.
Зато посмотрел что сделалось за день, слил лишние коммиты в один и потом пушишь — очень удобно :)
Вот КАК в Mercurial сливать лишние коммиты в один? Пробовал плагины, но не помогают — лезут изо всех дыр.
Простите, пользуюсь git. Но пишут что в Меркуриале тоже допили rebase.
И всё равно в git'е больше функциоанльности.
Например? (не холивара ради, просто интересуюсь)
Касательно rebase?
Судя по манам,
Судя по манам,
hg умеет только hg rebase --collapse, который склеивает коммиты в один. А git умеет git rebase -i, который может коммиты склеивать, переписывать комментарии к ним, менять местами.
В последний раз при общении на подобную тему, например, мне так и не смогли рассказать как сделать при помощи меркуриала раздельное хранение метаданных и собственно файлов сайта + не сообщили можно ли сделать промежуточный сервер с репозиториями исходных кодов сайтов, при пуше на которые автоматически обновлялись сайты.
1. Насколько я понял эта команда откатывает состояние рабочей папки до 0й ревизии (когда был сделан init), даже не представляю как это может пригодиться и что потом с этим делать, но я совсем про другое, в гите метаданные (папка .git) и рабочие файлы легко разделяются (1 строка в конфиге), что обеспечивает безопасное хранение исходников и рабочую папку без «мусора», каким образом это делается в Mercurial?
2. Каким образом? В git добавляется в хук получения данных строка с пушем на сайт(можно и несколько назначений туда указать), соотв 1 строчка, а столько удовольствия.
Причём никаких суперзнаний для этого не надо всё есть в книге.
2. Каким образом? В git добавляется в хук получения данных строка с пушем на сайт(можно и несколько назначений туда указать), соотв 1 строчка, а столько удовольствия.
Причём никаких суперзнаний для этого не надо всё есть в книге.
1. Потому что любая ошибка в настройке веб сервера приведёт к тому что эти данные будут доступны общественности, вспомните массовые взломы сайтов когда додумались проверять данные SVN репозиториев, а храня метаданные отдельно можно вообще не беспокоиться об этом да и глаза не мозолят лишние папки и файлы и удалить ничего лишнего случайно не удастся, в общем одни плюсы.
2. Да, с хуками всё вполне реализуемо.
2. Да, с хуками всё вполне реализуемо.
1. После вашего вопроса, тоже вспомнил эту историю с публично-доступными .svn
Я обычно делаю публичной не всю папку репозитория, а какую-нибудь www внутри. Т.о. репозиторий оказывается на один уровень выше.
Я обычно делаю публичной не всю папку репозитория, а какую-нибудь www внутри. Т.о. репозиторий оказывается на один уровень выше.
Я очень рад, что за последние пару лет в hg появился этот функционал, пусть его и не включают в основную сборку. Так что не стоит растрачивать сарказм понапрасну :)
Пробовал — ерунда получается. Пушу коммиты на «центральный» реп, делаю ребэйз, пушу опять — старые не исчезают.
Попробуйте наоборот:
1. работаю, много комичу
2. rebase (на локальной машине)
3. push на «центральный» реп
Заодно задам вопрос по git:
если сначала запушить много комитов на удалённый репозиторий, потом локально сделать rebase, и запушить новый результат на удалённый репозиторий — не уже ли на удалённом репозитории исчезнет пачка комитов запушеная в первый раз? Если да, значит git при пуше передаёт не только сами комиты, но и другую мета-информацию, в частности структуру поделанного локально rebase? Как-то сложно получается… Как на самом деле в git?
1. работаю, много комичу
2. rebase (на локальной машине)
3. push на «центральный» реп
Заодно задам вопрос по git:
если сначала запушить много комитов на удалённый репозиторий, потом локально сделать rebase, и запушить новый результат на удалённый репозиторий — не уже ли на удалённом репозитории исчезнет пачка комитов запушеная в первый раз? Если да, значит git при пуше передаёт не только сами комиты, но и другую мета-информацию, в частности структуру поделанного локально rebase? Как-то сложно получается… Как на самом деле в git?
Да, припоминаю, читал об этом. Кажется, эти «скрытые» комиты будут почищены сборщиком мусора через 30 дней (поправьте, если я что-то перепутал).
Тогда еще вопрос: а если до того как я запушил свой rebase, кто-то успел сделать pull этой пачки комитов, поработать над ними и сделать push обратно (по времени, допустим, после моего rebase-push) — куда теперь будет указывать master? Должен возникнуть конфликт указателя master?
Поясню природу своего вопроса: в mercurial такая ситуация не вызывает у меня проблемы, получатся анонимные ветки и их может быть сколь угодно много и они не будут однажды внезапно подчищены сборщиком мусора.
Тогда еще вопрос: а если до того как я запушил свой rebase, кто-то успел сделать pull этой пачки комитов, поработать над ними и сделать push обратно (по времени, допустим, после моего rebase-push) — куда теперь будет указывать master? Должен возникнуть конфликт указателя master?
Поясню природу своего вопроса: в mercurial такая ситуация не вызывает у меня проблемы, получатся анонимные ветки и их может быть сколь угодно много и они не будут однажды внезапно подчищены сборщиком мусора.
Серьёзно? Пошёл проверять, но ИМНИП нужно
git push --force сделать в таком случае. А старые коммиты можно удалить если перепаковать дерево, тогда не получится достучаться.Про то как пользоваться mercurial`ом и команды рассказывать не буду, т.к. на их сайте полно документации.— зря. Как раз этого не хватает.
На разных проектах приходилось использовать разные системы версий и всегда была одна и таже мысль — какое же это убогое убожество с точки зрения клиентского ПО.
Более менее приемлимый уровень имеет TortoiseSVN. Остальными (тем же Tortoise HG для mercurial) пользоваться сложно и неудобно, приходится с командной строки и тратить время на чтение документации. Получается что очень много ресурсов уходит на вспомогательную работу а если брать для этого отдельного работника то для небольших проектов будет неоправданно дорого.
> брать для этого отдельного работника
для чего, чтобы документацию читал?
для чего, чтобы документацию читал?
в том числе и для этого. Всё стоит денег, а качество ПО, когда всё интуитивно понятно и не требует дополнительной работы, ведёт к снижению затрат (ну, в идеале конечно).
а) На хабре уже есть серия из кажется 6 статей Джоэля Спольски с описанием и команд, и воркфлоу и всего чего угодно.
б) Понятие «интуитивный интерфейс» очень относительно. Лично мне, как разработчику привыкшему общаться с компьютером путем отдачи команд на гибких формализованных языках, работать с консолью сильно проще, чем лезть за мышкой и нажимать на кнопки. А главное — продуктивнее. И выигрыш по времени ВНЕЗАПНО окупает изучение документации (не говоря о том, что это прокачивает мозги и помогает понять как на само деле работает продукт).
б) Понятие «интуитивный интерфейс» очень относительно. Лично мне, как разработчику привыкшему общаться с компьютером путем отдачи команд на гибких формализованных языках, работать с консолью сильно проще, чем лезть за мышкой и нажимать на кнопки. А главное — продуктивнее. И выигрыш по времени ВНЕЗАПНО окупает изучение документации (не говоря о том, что это прокачивает мозги и помогает понять как на само деле работает продукт).
Во первым интерфейс коммандной строки — это не конец света, даже для того-же SVN. Это совсем не сложно и удобно. Даже при наличии TortoiseSVN и под виндоуз я в большинстве командной строкой, так на порядок эффективнее и быстрее, чем с оболочкой. Во вторых, для любителей гуя TortoiseHG тоже вполне себе неплохо работает. В третих, мне тут недавно довелось из эклипса поработать, так вот интеграция Mercuriala оказалась гораздо удобнее и качественнее интеграции с SVN.
ну зачем тратить время на это? Это же даже не разработка а поддержка работы. Работать-то когда?
На одном крупном проекте использовался Rational ClearCase. Там было всё (вообще всё), стоил кучу денег. Но всё равно проще было с командной строки некоторые вещи делать. А ведь 21 век и даже в телефонах виндовс с красивыми кнопочками стоит.
На одном крупном проекте использовался Rational ClearCase. Там было всё (вообще всё), стоил кучу денег. Но всё равно проще было с командной строки некоторые вещи делать. А ведь 21 век и даже в телефонах виндовс с красивыми кнопочками стоит.
На что тратить то?
на чтение документации и изучение продукта, на организацию процесса, на поддержку процесса.
Большая зелёная кнопка «сделать хорошо» меня бы вполне устроила.
Большая зелёная кнопка «сделать хорошо» меня бы вполне устроила.
Системы контроля версий дают достаточно преимуществ, чтобы потратить несколько часов на изучение десятка основных команд. Для совсем новичков есть статья «hg init».
После изучения и небольшого привыкания на поддержку процесса не будет уходить много времени. Все команды просты и логичны, поэтому быстро запоминаются. Если вы достаточно быстро печатаете, вам будет проще и быстрее набрать «hg commit -m «Initial Release»», чем сделать это же через GUI.
После изучения и небольшого привыкания на поддержку процесса не будет уходить много времени. Все команды просты и логичны, поэтому быстро запоминаются. Если вы достаточно быстро печатаете, вам будет проще и быстрее набрать «hg commit -m «Initial Release»», чем сделать это же через GUI.
я часто с такой позицией сталкивался и во многих областях. Типа «наш продукт слишком сложен чтоб сделать удобно».
Заканчивалось всё всегда одинаково — появлялся конкурент который решал проблемы пользователя (т.е. делал более удобной работу) и пользователи на него перескакивали.
Заканчивалось всё всегда одинаково — появлялся конкурент который решал проблемы пользователя (т.е. делал более удобной работу) и пользователи на него перескакивали.
Вы просто не представляете, на сколько Mercurial удобен :)
Вы же не программируете «методом тыка». Здесь тоже такой способ не подходит — необходимо читать документацию, чтобы понять, какие методы организации процесса разработки предлагает Mercurial, и что из этого вам будет удобно использовать.
Вы же не программируете «методом тыка». Здесь тоже такой способ не подходит — необходимо читать документацию, чтобы понять, какие методы организации процесса разработки предлагает Mercurial, и что из этого вам будет удобно использовать.
А что вы сказать то хотите? Что лучше вообще без СКВ, потому, что «разбираться долго»? Или вы утверждаете, что разобраться с SVN намного проще, чем с Mercurial?
я тут написал
http://habrahabr.ru/post/140496/#comment_4695482
посетовал на пользовательское неудобство всех систем контроля версий (в том числе и hg и коммерческих дорогих типа ClearCase) с которыми работал.
http://habrahabr.ru/post/140496/#comment_4695482
посетовал на пользовательское неудобство всех систем контроля версий (в том числе и hg и коммерческих дорогих типа ClearCase) с которыми работал.
Так что вы предлагаете? Вообще отказаться от СКВ? Или вы просто потроллить?
Что значит «предлагаете»? Я же камент написал к статье а не собственную статью. В каменте отметил недостатки присущие системам версий которые редко освящаются в публикация.
Наверное, потому что они на самом деле не недостатки?
данная тема за пару часов набрала больше сотни каментов. Причём каждый с пеной у рта доказывает именно его-то тул (hg, git, неважно) чем-то лучше других и отметает любые аргументы.
Процесс самой разработки с таким жаром не обсуждают как этот второстепенный вспомогательный инструмент.
Это говорит о том что проблемы есть.
Процесс самой разработки с таким жаром не обсуждают как этот второстепенный вспомогательный инструмент.
Это говорит о том что проблемы есть.
Это холивар из серии Linux/Windows, не стоит принимать во внимание. В топиках про SVN такого нету по той лишь причине, что в своей категории сравнивать не с чем.
А заметное различие между git и hg по сути только одно: разная логика работы с ветками. Но об этом пока ещё никто не вспоминал тут :) Просто трепемся и обмениваемся новостями.
А заметное различие между git и hg по сути только одно: разная логика работы с ветками. Но об этом пока ещё никто не вспоминал тут :) Просто трепемся и обмениваемся новостями.
Обычная ситуация — сейчас потратить немного (относительно), а потом экономить. Обычное избегание «велосипедостроения».
в больших конторах целые отделы этим занимаются. Дорого очень. Иногда получается что дешевле купить коммерческую чем тратить время на бесплатное.
Комерческие они всегда удобнее? Лол, может вы про ClearCase или VSS? :))
у вас есть какие-то претензии к ClearCase? Или к VSS который сейчас уже имеет другое имя?
У меня очень много претензий к обоим.
СС — это страшный монстр, довольно мощный, но дико неудобный, ужасно медленный, очень сложный в использование и поддержке, с ужасным гуем (во всяком случае под *nix) и баснословно дорогой. Одна рекомендация бывшего rational-а о том, что для администрации CC нужен фул-тайм человек на каждые 20-30 девелоперов, уже о многом говорит. Это классический пример, энетерпрайз-корпоротивной хни, которую сейлсмены продают топ-менеджерам на коктель-вечеринках и играх в гольф, а весь технических персонал потом хватается за голову, и не знает, за какие такие грехи, на них свалилось это «счастье».
VSS — про новую версию, которая по другому называется, я ничего не знаю, но старая — это унылое, не на что не годное говно, которое вообще не тянет на то, что бы называться СКВ, так как ничего из того, что должена уметь делать СКВ оно или вообще не умеет, или умеет очень криво и ненадежно.
СС — это страшный монстр, довольно мощный, но дико неудобный, ужасно медленный, очень сложный в использование и поддержке, с ужасным гуем (во всяком случае под *nix) и баснословно дорогой. Одна рекомендация бывшего rational-а о том, что для администрации CC нужен фул-тайм человек на каждые 20-30 девелоперов, уже о многом говорит. Это классический пример, энетерпрайз-корпоротивной хни, которую сейлсмены продают топ-менеджерам на коктель-вечеринках и играх в гольф, а весь технических персонал потом хватается за голову, и не знает, за какие такие грехи, на них свалилось это «счастье».
VSS — про новую версию, которая по другому называется, я ничего не знаю, но старая — это унылое, не на что не годное говно, которое вообще не тянет на то, что бы называться СКВ, так как ничего из того, что должена уметь делать СКВ оно или вообще не умеет, или умеет очень криво и ненадежно.
Кстати, в плане поддержи, по моим наблюдениями mercurial требует меньших затрат. Когда я поддерживал SVN репозиторий для небольшой компании, в которой я работал — это были постоянные проблемы со всякими lock-ами, эклипсами, сломанными локальными копиями (когда то-то случайно удалял из поддиректории .svn или копировал его с данными из другой копии получая дерево со смешанными версиями), неудачными мержами и т.д. и т.п. С меркуриал с такими проблемами просто не сталкивался, хотя сейчас активно с ним работаю.
Tortoise — если не ошибаюсь, это обёртка для mercurial`а, предназначенная для интеграции в графический менеджер. Сам по себе mercurial — консольное приложение и в плане команд отлично описан в man`ах и документации на сайте (правда на английском). Как пользователя Linux, привыкшего к командной строке и её возможностям, в этом плане mercurial меня полностью удовлетворяет. А чтение документации необходимо в любом случае для понимания того, что происходит.
На Хабре был цикл о Mercurial…
>а коммиты то зачем?
Затем, чтобы обновиться на любой из комитов и получить рабочую систему.
Затем, чтобы обновиться на любой из комитов и получить рабочую систему.
Комментарием ниже посмотрите git'овский workflow, там очень красиво решена проблема доступности рабочей версии проекта.
И нафига? Рабочие версии системы (релизы, ночные билды, прошедшие qa/unit test и т.д.) — отмечаются тагами или бранчами. А коммиты — они для программистов.
Расскажете мне про это, когда будете искать коммит, на котором появился баг и найдете кучу коммитов, на которых вы не сможете определить его наличие или отсутствие из-за того, что система просто нерабочая.
Да без проблем — есть куча всяких способов найти что и когда менялось, всякие annotate/blame и и.д. А найти баг и его изолировать как раз гораздо удобнее когда коммиты это не огромная пачка изменений вместе («фичер Х») а небольшие правки «переписал функцию Х», «поменял настройки конфига» и т.д.
Вообщем как по мне — требование «работающих» коммитов в случае DVCS — это неправильная организация работы, фашизм по отношению к разработчикам и излишняя бюрократизация. Все это по любому не на пользу рабочему процессу.
Вообще, чем меньше условностей и бюрократических требований — тем лучше. Скажем багтрекером, в котором десяток обязательных полей — будут пользоваться гораздо меньше, чем удобным багтрекером, в котором можно создать баг одной строчкой. Бюрократы будут недовольны, но лучше баг занесенный в систему с фиговым описанием, чем баг который вообще не был занесен в систему. Так и VCS — лучше еще пару ревизий, которые может и будут мозолить глаза начальнику при просмотре дерева, чем «ой мамочки, я случайно стер файл и день работы пошел коту под хвост».
Вообщем как по мне — требование «работающих» коммитов в случае DVCS — это неправильная организация работы, фашизм по отношению к разработчикам и излишняя бюрократизация. Все это по любому не на пользу рабочему процессу.
Вообще, чем меньше условностей и бюрократических требований — тем лучше. Скажем багтрекером, в котором десяток обязательных полей — будут пользоваться гораздо меньше, чем удобным багтрекером, в котором можно создать баг одной строчкой. Бюрократы будут недовольны, но лучше баг занесенный в систему с фиговым описанием, чем баг который вообще не был занесен в систему. Так и VCS — лучше еще пару ревизий, которые может и будут мозолить глаза начальнику при просмотре дерева, чем «ой мамочки, я случайно стер файл и день работы пошел коту под хвост».
Не надо передергивать, я не говорил про огромные пачки изменений. Я говорил о том, что надо иметь культуру и думать о других программистах, которые будут работать с вашим кодом.
>Вообщем как по мне — требование «работающих» коммитов в случае DVCS… и далее поскипано
Такие вопросы:
1) сколько строк кода в вашем самом большом проекте(я не имею в виду проект в IDE)?
2) сколько лет вашему самому долгоиграющему проекту?
3) сколько в вашей команде разработчиков?
>Вообщем как по мне — требование «работающих» коммитов в случае DVCS… и далее поскипано
Такие вопросы:
1) сколько строк кода в вашем самом большом проекте(я не имею в виду проект в IDE)?
2) сколько лет вашему самому долгоиграющему проекту?
3) сколько в вашей команде разработчиков?
Думать надо о других, это точно. Надо писать внятные комментарии к коммитам, не коммитить ненужные файлы (попадаются любители добавлять все, включая сгенерированные и объектные файлы) и т.д. А вот «работающий код» — это очень относительная штука. Как вы сами определяете? Код компилируется? Код запускается? Прошей unit-тесты? Прошей автоматическую проверку? Прошел QA? Это все разные степени «работает», и я не вижу почему до какой-то степени можно делать коммит, а потом нет? На счет технической стороны — все равно для больших проектов будут десятки тысяч коммитов, системы с этим прекрасно справляются, они на это рассчитаны, есть куча инструментов, для того что бы внутри них эффективно управлять версиями, релизами и ветками. Так что пару коммитов туда или сюда — погоды точно не сделают. К тому-же, в распределенных систмах опять таки не все локальные коммиты обязаны попадать в центральный репозиторий — можно и патчи отсылать.
А насчет опыта — я не вижу смысла мерятся шворцами. Я сейчас вообще фрилансер, но и работал над очень крупными проектами в больших компаниях.
А насчет опыта — я не вижу смысла мерятся шворцами. Я сейчас вообще фрилансер, но и работал над очень крупными проектами в больших компаниях.
>Как вы сами определяете?
Я определил это правилами внутреннего распорядка и записал, какие свойства обязаны быть у коммита.
>Так что пару коммитов туда или сюда — погоды точно не сделают.
Я говрил не о количестве, а о качестве коммитов.
>А насчет опыта — я не вижу смысла мерятся шворцами
Я не меряться предлагал, а просто хотел понять, почему вы не понимаете таких простых вещей.
Я определил это правилами внутреннего распорядка и записал, какие свойства обязаны быть у коммита.
>Так что пару коммитов туда или сюда — погоды точно не сделают.
Я говрил не о количестве, а о качестве коммитов.
>А насчет опыта — я не вижу смысла мерятся шворцами
Я не меряться предлагал, а просто хотел понять, почему вы не понимаете таких простых вещей.
Ох уж вы любители всю бюрократизировать. :) Я вас спросил чем вы руководствуетесь, а вы отвечаете «потому, что я так решил и записал». Правила и гайдлайны — это хорошо, но зачем просто так разводить тиранию?
Про качество я не спорю даже, я не говорю про коммитить каждую запятую, а про то, что девелоперы сами должны решать, когда и почему их удобно делать коммиты и где проходят их рамки логических кусков. Но почему-то вы решили для себя, что минимальная гранулярность работающего кода — один коммит, а я пытаюсь понять, какие есть технические или организационные причины так делать. «Так надо» — это не довод, потому, что я вижу огромное количество проектов, где отлично работаю без таких ограничений. Плюс всегда есть инструменты для того, что бы «схлопывать» мелкие коммиты — можно их делать только локально, отсылать патчи, можно объединять их rebase-ами или его аналогами.
А про «простые вещи» — это глупый наезд. Ваше мнение, как им мое, от него отличающиеся — не истина в последней инстанции. Мне вот, например, очевидно, что VCS призваны облегчить работу программистам а не усложнять её дополнительной бюрократией, но я же заявляю вам «как вы таких элементарных вещей не понимаете»? Держитесь в рамках цивилизованной дискуссии…
Про качество я не спорю даже, я не говорю про коммитить каждую запятую, а про то, что девелоперы сами должны решать, когда и почему их удобно делать коммиты и где проходят их рамки логических кусков. Но почему-то вы решили для себя, что минимальная гранулярность работающего кода — один коммит, а я пытаюсь понять, какие есть технические или организационные причины так делать. «Так надо» — это не довод, потому, что я вижу огромное количество проектов, где отлично работаю без таких ограничений. Плюс всегда есть инструменты для того, что бы «схлопывать» мелкие коммиты — можно их делать только локально, отсылать патчи, можно объединять их rebase-ами или его аналогами.
А про «простые вещи» — это глупый наезд. Ваше мнение, как им мое, от него отличающиеся — не истина в последней инстанции. Мне вот, например, очевидно, что VCS призваны облегчить работу программистам а не усложнять её дополнительной бюрократией, но я же заявляю вам «как вы таких элементарных вещей не понимаете»? Держитесь в рамках цивилизованной дискуссии…
Я ни разу не любитель бюрократизировать:) Я говорю так исходя из опыта командой в 20 человек. Деввелоперы не всегда способны решать правильно, для этого и существуют гайдлайны, инструкции и т.п.
>девелоперы сами должны решать, когда и почему их удобно делать коммиты и где проходят их рамки логических кусков
Ну, вы же не станете спорить, что для команды обязательно соглашение о стиле кода — так почему же вы спорите с тем, что я хочу установить такое же соглашение для комитов?
Ну, и никаких наездов, vcs нужны для облегчения жизни, но не только. Они так же нужня для контроля, потому они и называются vCs ;)
>девелоперы сами должны решать, когда и почему их удобно делать коммиты и где проходят их рамки логических кусков
Ну, вы же не станете спорить, что для команды обязательно соглашение о стиле кода — так почему же вы спорите с тем, что я хочу установить такое же соглашение для комитов?
Ну, и никаких наездов, vcs нужны для облегчения жизни, но не только. Они так же нужня для контроля, потому они и называются vCs ;)
Хотел согласится с Zigmar, но понял что руководствуюсь тем же принципом, что XuMiX. Потому, что никому не интересны бессмысленные коммиты, которые тем более ломают программу (в любой может понадобиться обновиться до конкретного коммита и искать «где там последнее рабочее состояние» довольно утомительно).
Если же девелоперу очень надо сделать пару бессмысленных коммитов, можно их сделать никому не показывая: откатить и накатить обратно изменения патчем в конце работы или, если в git, сделать squash. И история будет чище, и все коммиты будут рабочие.
Если же девелоперу очень надо сделать пару бессмысленных коммитов, можно их сделать никому не показывая: откатить и накатить обратно изменения патчем в конце работы или, если в git, сделать squash. И история будет чище, и все коммиты будут рабочие.
Все коммиты в стабильной ветке — да. Но откатываться внутри feature ветки может понадобиться только программисту, так что не вижу причины это ограничивать. Ничто не мешает пометить этот коммит в комментарии как недоделанный. В конце концов, при разработки какой-то большой части функционала так или иначе первые коммиты не очень рабочие получаются, значит какую-то разумную свободу в правилах тоже нужно указать.
Ну я парой комментариями выше как раз написал, что есть достаточно средств, что бы хранить историю в чистом и аккуратном виде, вводить для этого искусственные ограничения я не вижу смысла. Мне вообще кажется, что нужно логически/организационно различать несколько уровней. Скажем мержи в главную ветку коммитятся только после прохождения полного комплекта юнит-тестов, в ветку группы разработчиков, должно идти то, что как минимум компилируеться и желательно запускаться, а в своих локальные репозиториях/ветках девелопер волен делать все, что его душе угодно.
Вы, кстати, уходите от вопроса. Так что у вас в правилах написано по этому поводу? :)
Буквально вчера начал применять этот workflow для моих репозитариев в hg — очень много проблем решает, в том числе с наличием быстрого доступа к последней рабочей\dev версии и т.д.
В свете этого, думаю что патчи всё же больше созданы для того, чтобы быстро поделиться куском кода\заплаткой\новой фичей с коллегой из параллельной ветки разработки (feature branch).
В свете этого, думаю что патчи всё же больше созданы для того, чтобы быстро поделиться куском кода\заплаткой\новой фичей с коллегой из параллельной ветки разработки (feature branch).
Я использую hg branches, пока только начал, т.к. только сейчас накопил достаточный опыт, чтобы не накосячить сильно)
Насколько удобно — покажет время, но пока что всё идет хорошо.
Насколько удобно — покажет время, но пока что всё идет хорошо.
Ну как видите, в оригинальном мане предлагается также не терять бранчи везде используя флаг --no-ff, даже для короткоживущих бакфиксов.
А что плохого в том что они вечны? Вы же благодаря этому сможете отследить весь цикл разработки в обратную сторону. Просто закрываете ненужные ветки после слияний и всё будет ок — на том же bitbucket по умолчанию видны только открытые, так что они не должны сильно мешать.
А что плохого в том что они вечны? Вы же благодаря этому сможете отследить весь цикл разработки в обратную сторону. Просто закрываете ненужные ветки после слияний и всё будет ок — на том же bitbucket по умолчанию видны только открытые, так что они не должны сильно мешать.
Из моего опыта: глобальные ветки, такие как develop и stable — это hg branch.
Для короткоживущих и хотфиксов можно было бы использовать bookmarks, но как-то мне всё время лень создавать эти букмарки и я обхожусь анонимными ветками внутри develop (или в stable, если это очень горячий фикс).
Следующий вопрос, что потом делать с этими анонимными ветками? В большинстве случаев делаю обычный merge. Иногда, перед merge причёсываю свои комиты через mq import/fold.
Пробовал пользоваться и rebase, но мне приятнее видеть историю моих анонимных веток-фичей в виде отдельных комитов рядом с основной develop веткой. Кстати, какую из анонимных develop веток называть «основной» если все они анонимные? Выбрать любую условную, можно на неё даже отдельный bookmark повесить. Но сложность моих проектов не так велика, чтобы запутаться в 2-5 анонимных ветках в develop бренче.
Наконец, самая большая трудность возникает тогда, когда кто-то из команды внезапно сделает pull с моего репозитория. По умолчанию в mercurial pull и push синхронизирует все бренчи, все ветки. После такой глобальной синхронизации с соседом, причесать свои анонимные ветки используя mq import/fold не получится, т.к. непричёсанная история вернётся ко мне при следующей синхронизации с соседом. Вот тут есть некое преимущество у git с его приватными бренчами. Обходной путь в mercurial — это ветвление через клонирование. Можно наделать клонов в разных папках и не бояться, что их кто-то случайно стянет. Но это создаёт больше проблем, чем удобств — придётся настраивать IDE и другое окружение на несколько папок.
Однако реальная практика показывает, что особой проблемы с отсутствием приватных бренчей в mercurial нет. Просто так никто не делает pull с моего репозитория. Обычно коллеги делают pull непосредсвенно с моего компьютера, если я сам кому-то говорю «сделай с меня pull, я внёс важные фиксы».
Для короткоживущих и хотфиксов можно было бы использовать bookmarks, но как-то мне всё время лень создавать эти букмарки и я обхожусь анонимными ветками внутри develop (или в stable, если это очень горячий фикс).
Следующий вопрос, что потом делать с этими анонимными ветками? В большинстве случаев делаю обычный merge. Иногда, перед merge причёсываю свои комиты через mq import/fold.
Пробовал пользоваться и rebase, но мне приятнее видеть историю моих анонимных веток-фичей в виде отдельных комитов рядом с основной develop веткой. Кстати, какую из анонимных develop веток называть «основной» если все они анонимные? Выбрать любую условную, можно на неё даже отдельный bookmark повесить. Но сложность моих проектов не так велика, чтобы запутаться в 2-5 анонимных ветках в develop бренче.
Наконец, самая большая трудность возникает тогда, когда кто-то из команды внезапно сделает pull с моего репозитория. По умолчанию в mercurial pull и push синхронизирует все бренчи, все ветки. После такой глобальной синхронизации с соседом, причесать свои анонимные ветки используя mq import/fold не получится, т.к. непричёсанная история вернётся ко мне при следующей синхронизации с соседом. Вот тут есть некое преимущество у git с его приватными бренчами. Обходной путь в mercurial — это ветвление через клонирование. Можно наделать клонов в разных папках и не бояться, что их кто-то случайно стянет. Но это создаёт больше проблем, чем удобств — придётся настраивать IDE и другое окружение на несколько папок.
Однако реальная практика показывает, что особой проблемы с отсутствием приватных бренчей в mercurial нет. Просто так никто не делает pull с моего репозитория. Обычно коллеги делают pull непосредсвенно с моего компьютера, если я сам кому-то говорю «сделай с меня pull, я внёс важные фиксы».
Похоже вам не хватает hg lbranch.
Долгое время использовали этот вокрфлоу, пока геймдевом занимался. Решает огромное количество проблем. Каждой фиче (а фичи иногда были такие, что приходилось перепиливать до четверти проекта) — свою ветку, потом в отдельной веточке (или в девелопмент ветке, тут зависит от сложности всего этого) собираем клевый билд (оставляя не у дел фичи незавершенные, который никому при этом не мешают), после уже в девелопмент, а там и в мастер попадает (т.е. на релиз). Оверхед на всякие мержи и бранчевания был минимальный, конфликты решались быстро и просто. Подобные вещи на svn я делал гораздо дольше и матерясь на всю комнату.
Как было до этого? Одна ветка багоправки, фичи — все туда, что не успелось к релизу — забивалось комментами и стабами, поэтому иногда могло отваливаться, подтупливать и вылезать наружу. Одним словом неприятная ситуация.
Как было до этого? Одна ветка багоправки, фичи — все туда, что не успелось к релизу — забивалось комментами и стабами, поэтому иногда могло отваливаться, подтупливать и вылезать наружу. Одним словом неприятная ситуация.
Я использую mercurial еще и как средство резервного копирования. После создания репозитория делаю его клон на другом физическои диске и потом в процессе работы проталкиваю туда все изменения после коммитов. И уже не надо думать о бэкапах. Очень удобно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Mercurial: с чего начать внедрение и зачем нужны патчи