Комментарии 200
В первом опросе я использовал опрос с множественным выбором… Вроде. А так очень, очень сложно ответить, большинство, я уверен, пользуется активно не менее чем двумя VCS…
Тенденции радуют. CVS мёртв, SVN активно сдаёт позиции, Git — лидер. Mercurial, правда, странно выглядит. По сравнению с прошлым годом просел. Так что рост git в основном идёт за счёт пользователей SVN и Mercurial.
Что ж, отлично.
Что ж, отлично.
За меркуриал скажите спасибо гитхабу, как основному популяризатору git, и битбакету, введшему поддержку git, чтобы, имхо, не терять рынок. Если раньше я метался между git и hg, предпочитая hg субъективно и из-за возможности создавать бесплатные закрытые репы на битбакете, и мучаясь с hg-git для синхронизации с гитхабом, то теперь репы git на битбакете без костылей, хотя hg вспоминаю добрым словом — субъективно он лучше и не используй я сторонние разработки, то работал бы с ним, но сторонние разработки вносят свои коррективы.
Слава богу CVS потихоньку погибает, а то так придёшь на новую работу, а там весь репозиторий на CVS, да ещё и всё «по взрослому» с кучей бренчей.
Жалко нельзя две выбрать, к примеру на работе человек может юзать одно средство, а вот придя домой учавствуя в гитхаб или битбакет проектах совершенно другое. Да и не важно какое чаще юзаешь, главное ведь результат. Отметил SVN, ибо юзается у дяди дающего денюжку
Я думаю всё показательно: раз у дяди svn, значит комманду (и вас) он или устраивает, или вы менее опытны в других чтобы свитчнуться, или вы не можете договориться на какой свичнуться. В любом случае это голос за svn :)
А почему бы и не SVN, особенно если проект на несколько человек? (не десятки). Я не вижу принципиальных преимуществ гитхаба в этом случае.
Другое дело, конечно — роль, которую гит сыграл для Open Source.
Другое дело, конечно — роль, которую гит сыграл для Open Source.
Холиварно говоря, преимущество такое: в DVCS локальные коммиты (я уж не говорю про ветки) — твоё личное дело, перед тем как их отправлять ты можешь их создать сколько угодно, откатывать, менять, склеивать, разделять, менять местами, редактировать сообщения, т.е. логично группировать изменения пост-фактум (как для себя, так и для ревью) и править регрессии прямо в плохих коммитах. В svn же 7 раз отмерь, один закоммить, и если нашел регрессию — придется делать новый фейспалм коммит. История фейлов, а не успехов. Плюс переключение между ветками ну действительно медленно в svn, и мгновенно в git/hg.
Почему же холиварно, скорее объективно. Просто в небольших не-энтерпрайз проектов не очень хороший коммит не так уж и критичен, да и у хороших девелоперов не так часто бывает. А так по мне что гит что свн использовать — всё одно, лишь бы не бэкапы файлов (удивлён, но до сих пор встречаю программеров и за 50, и до 25-ти, которые не пользуются VCS вообще)
Возможно, одна из причин популярности SVN в закрытых проектах — как раз из-за того, что «в DVCS локальные коммиты (я уж не говорю про ветки) — твоё личное дело». Разработчиков сидящих в SVN проще контролировать.
После перехода с SVN на Mercurial я обнаружил преимущество, про которое почему-то почти никто не говорит (я не встречал), но которое стало для меня решающим (в SVN я больше ни ногой).
В hg я могу закоммитить свои изменения и только после этого, когда я захочу запушить изменения в общий репозиторий, от меня потребуют смержить их с изменениями других разработчиков.
В SVN при попытке коммита от меня сразу требуют выполнить мерж, т.е. перед коммитом я вынужден обновиться из репозитория и смержить изменения. В результате в SVN я вообще не имею возможности зафиксировать в репозитории свою версию в чистом виде без привнесенных извне модификаций.
Фактически это срабатывает так: я пишу код, тестирую его, пишу документацию, делаю все очень аккуратно и я уверен, что в коде нет проблем. Одновременно запас моей аккуратности на сегодня исчерпан. Я хочу закоммититься и вдруг обнаруживаю, что мне сейчас придется обновиться и смержиться. Я делаю это второпях, возможно не замечая изменений, которые, например, изменяют контракт, на который я рассчитывал. В результате мой тщательно вылизанный коммит вносит в систему баг. Причем потом бывает трудно выяснить, внесен баг моими изменениями, изменениями, полученными при обновлении, или образовался в результате взаимодействия этих изменений. Впрочем, даже сами эти типы изменений бывает трудно отличить при просмотре дифа моей ревизии. Самое неприятное, что сами мои изменения в их изначальном виде нигде не сохраняются и оказываются потерянными. Т.е. потом при поиске первой ревизии с багом никак не удастся выяснить, какие конкретно изменения виноваты.
В hg я могу закоммитить свои изменения и только после этого, когда я захочу запушить изменения в общий репозиторий, от меня потребуют смержить их с изменениями других разработчиков.
В SVN при попытке коммита от меня сразу требуют выполнить мерж, т.е. перед коммитом я вынужден обновиться из репозитория и смержить изменения. В результате в SVN я вообще не имею возможности зафиксировать в репозитории свою версию в чистом виде без привнесенных извне модификаций.
Фактически это срабатывает так: я пишу код, тестирую его, пишу документацию, делаю все очень аккуратно и я уверен, что в коде нет проблем. Одновременно запас моей аккуратности на сегодня исчерпан. Я хочу закоммититься и вдруг обнаруживаю, что мне сейчас придется обновиться и смержиться. Я делаю это второпях, возможно не замечая изменений, которые, например, изменяют контракт, на который я рассчитывал. В результате мой тщательно вылизанный коммит вносит в систему баг. Причем потом бывает трудно выяснить, внесен баг моими изменениями, изменениями, полученными при обновлении, или образовался в результате взаимодействия этих изменений. Впрочем, даже сами эти типы изменений бывает трудно отличить при просмотре дифа моей ревизии. Самое неприятное, что сами мои изменения в их изначальном виде нигде не сохраняются и оказываются потерянными. Т.е. потом при поиске первой ревизии с багом никак не удастся выяснить, какие конкретно изменения виноваты.
Согласен.
Добавлю еще несколько слов по поводу того что дал мне Mercurial и чего не может дать мне SVN используемый на работе.
Резюме нижесказанного: Mercurial поощряет экспериментирование без которого, нам разработчикам, иногда не возможно развиваться или решать задачи.
Иногда в нашем мозгу возникают идеи, которые похожи на бред, но тут же возникает другая мысль: «А вдруг? Почему нет?». Для того чтобы получить ответ на вопрос: «бред или нет?» мы должны хотя бы немножко, хотя бы чуть-чуть этот бред запилить. При повседневном использовании Меркуриала мы замечаем, что все вертится вокруг одной папки это '.hg'. После того как мы после 2 дней экспериментирования понимаем, что мы написали бред, то мы просто удаляем одну папку! Наши попытки «наговнокодить» никакого не задели, ни физически, ни морально(а ведь на это же мог кто-то поглядеть :)))
1)
Можете ли Вы пользуясь SVN также быстро получать ответы на свои вопросы и при этом ни кого не трогая без особой нужды?
2)
Если Ваш коллега сидит от Вас за 7-8 метров и ему лень вставать(как часто Вы слышали: «Путь, ну млин, айда позже?»). В меркуриал это одна команда «hg serve». Вы поднимаете у себя локально вэб-сервер и даете ссылку по аське, жаберу или идете лично и вбиваете ему в гугле-хроме(или еще где) и человеку уже не отвертеться «гора сама пришла»
3)
Насколько легко вы мержите ветки? И как часто их применяете? Не знаю, может у меня руки не из правильного места, но в SVN мержить ветки так и не научился. А в Mercurial это все как будто само за меня делается. Я к тому что сложности юзания веток не только у меня, но и у других, даже матерые девелоперы избегают этой процедуры. Это выливается, что команда комитит в HEAD даже не рабочий код, только лишь из соображений «А вдруг я завтра не смогу придти на работу?». Меркуриал же поощрает «одна задача одна ветка и одна всесильная под названием stable»
4)
Безболезненая смена ответственного за фичу.
В любой момент разработки продукта могут пилиться абсолютно разные фичи по которым люди также имеют абсолютно разный уровень знания. Как вывод по новой разрабатываемой фиче куда выгоднее иметь разработчика который больше всего подходит именно для этой фичи и назначить его мантейнером. В случае SVN репа «гвоздями прибита» к одному компу, в случае Mercurial можно в любой момент времени создать репу на компе конкретного разработчика. Если же он вдруг меняется, у других ребят кто пилит с ним эту фичу есть локальные копии со всем необходимым и если мантейнер заболел, забухал или еще что, на команде это не сказывается.
Более-того, если все пилится по схеме «одна фичи одна ветка», то мантейнером за stable назначается тестировщик, что куда выгоднее. Команда всегда знает что от туда можно взять стабильно работающий код, ибо за него несет ответственность тестировщик.
Добавлю еще несколько слов по поводу того что дал мне Mercurial и чего не может дать мне SVN используемый на работе.
Резюме нижесказанного: Mercurial поощряет экспериментирование без которого, нам разработчикам, иногда не возможно развиваться или решать задачи.
Иногда в нашем мозгу возникают идеи, которые похожи на бред, но тут же возникает другая мысль: «А вдруг? Почему нет?». Для того чтобы получить ответ на вопрос: «бред или нет?» мы должны хотя бы немножко, хотя бы чуть-чуть этот бред запилить. При повседневном использовании Меркуриала мы замечаем, что все вертится вокруг одной папки это '.hg'. После того как мы после 2 дней экспериментирования понимаем, что мы написали бред, то мы просто удаляем одну папку! Наши попытки «наговнокодить» никакого не задели, ни физически, ни морально(а ведь на это же мог кто-то поглядеть :)))
1)
Можете ли Вы пользуясь SVN также быстро получать ответы на свои вопросы и при этом ни кого не трогая без особой нужды?
2)
Если Ваш коллега сидит от Вас за 7-8 метров и ему лень вставать(как часто Вы слышали: «Путь, ну млин, айда позже?»). В меркуриал это одна команда «hg serve». Вы поднимаете у себя локально вэб-сервер и даете ссылку по аське, жаберу или идете лично и вбиваете ему в гугле-хроме(или еще где) и человеку уже не отвертеться «гора сама пришла»
3)
Насколько легко вы мержите ветки? И как часто их применяете? Не знаю, может у меня руки не из правильного места, но в SVN мержить ветки так и не научился. А в Mercurial это все как будто само за меня делается. Я к тому что сложности юзания веток не только у меня, но и у других, даже матерые девелоперы избегают этой процедуры. Это выливается, что команда комитит в HEAD даже не рабочий код, только лишь из соображений «А вдруг я завтра не смогу придти на работу?». Меркуриал же поощрает «одна задача одна ветка и одна всесильная под названием stable»
4)
Безболезненая смена ответственного за фичу.
В любой момент разработки продукта могут пилиться абсолютно разные фичи по которым люди также имеют абсолютно разный уровень знания. Как вывод по новой разрабатываемой фиче куда выгоднее иметь разработчика который больше всего подходит именно для этой фичи и назначить его мантейнером. В случае SVN репа «гвоздями прибита» к одному компу, в случае Mercurial можно в любой момент времени создать репу на компе конкретного разработчика. Если же он вдруг меняется, у других ребят кто пилит с ним эту фичу есть локальные копии со всем необходимым и если мантейнер заболел, забухал или еще что, на команде это не сказывается.
Более-того, если все пилится по схеме «одна фичи одна ветка», то мантейнером за stable назначается тестировщик, что куда выгоднее. Команда всегда знает что от туда можно взять стабильно работающий код, ибо за него несет ответственность тестировщик.
Кстати, мы использовали SVN почти с момента его рождения (около 7 лет) и все время использовали ветки, причем вполне успешно. Ну а после выхода версии 1.5 почти полностью увели разработку в ветки. Так что в принципе особых проблем с этим в SVN нет, если не пытаться в ветке рефакторить структуру проекта.
В том-то и дело, что самые умные мысли приходят не сразу! А хорошо если в начале процесса разработки, но как правило либо где-то посередине, либо из-за обнаруженного нюанса, нового требования или еще чего-нить иногда и структуру проекта нужно изменять. Программисты, вообще о науке разработки ПО, уже пробовали спроектировать на самом первом этапе, не осилили и пришли к тому что сейчас более менее вменяемо это работа по Agile-практикам или около-них
Ну, изменение файловой структуры проекта в SVN это вообще ад, в который лучше погружаться, приостановив остальные работы. Иначе либо у выполняющего модификацию, либо у всех остальных начнется нешуточный батхерд.
>>изменение файловой структуры проекта
В меркуриал это:
$(ProjectRoot)>\ hg ci -A -m «Project file structure changed»
где:
В меркуриал это:
$(ProjectRoot)>\ hg ci -A -m «Project file structure changed»
где:
-A --addremove mark new/missing files as added/removed before committing
А переименования он как отслеживает?
Есть команда 'hg rename'. Она выполнена в виде 'hg delete'/'hg add', но с пометкой че и откуда и куда. Точно такое же поведение и 'hg move'. Юниксоиды так вообще предпочитают 'hg mv', мне говорят «что это им роднее», возможно…
ЗЫ:
Я не гуру, но пока сюрпризов не видел )
ЗЫ:
Я не гуру, но пока сюрпризов не видел )
Во-первых, если delete/add, то сохраняется ли история?
А во-вторых, ваш волшебный
А во-вторых, ваш волшебный
hg ci -A это, конечно же, не поддерживает?Сохраняется история! Это одно из требований при разработке Mercurial. К примеру в коммите писал одно «Added ReadPe class and module with the class», а вот в одном из информационном поле на файле помимо сообщения коммита в TortoiseHg показывается: «ReadPE/tools/readpe.py (was added)». Аналогичное поведение и для delete.
Это немножко не то.
Вот был файл A. У него было десять коммитов. Теперь его переименовали в B (по вашим словам, это delete-add). Будут ли в истории файла B видны коммиты файла А?
То есть, rename не умеет.
Собственно, основная-то проблема с изменениями файловой структуры проекта именно в этом.
Вот был файл A. У него было десять коммитов. Теперь его переименовали в B (по вашим словам, это delete-add). Будут ли в истории файла B видны коммиты файла А?
hg ci -A, умеет ровно то что умеют add/remove по отдельности.
То есть, rename не умеет.
Собственно, основная-то проблема с изменениями файловой структуры проекта именно в этом.
.
>>Будут ли в истории файла B
Проделал небольшой эксперимент на 'hg init proba'.
Что сделал?
1) добавил 1.txt
2) Заем изменил его
3) далее переименовал 'hg rename 1.txt 2.txt'
4) закомитил переименование
5) изменил 2.txt.
6) Посмотрел history на файл.
итог: Историю вижу вплоть до коммитов по 1.txt
>>То есть, rename не умеет
Я правильно понял, что use-case такой: Вы переименовали файл с помощью функций вашего bash или другой плюшки операционной системы и хотите от среды контроля версий чтобы она догадалась что вон тот файл на самом деле не просто добавлен, а что он ничто иное как переименованная копия прежнего файла?
Проделал небольшой эксперимент на 'hg init proba'.
Что сделал?
1) добавил 1.txt
2) Заем изменил его
3) далее переименовал 'hg rename 1.txt 2.txt'
4) закомитил переименование
5) изменил 2.txt.
6) Посмотрел history на файл.
итог: Историю вижу вплоть до коммитов по 1.txt
>>То есть, rename не умеет
Я правильно понял, что use-case такой: Вы переименовали файл с помощью функций вашего bash или другой плюшки операционной системы и хотите от среды контроля версий чтобы она догадалась что вон тот файл на самом деле не просто добавлен, а что он ничто иное как переименованная копия прежнего файла?
Историю вижу вплоть до коммитов по 1.txt
Значит, не delete/add.
Я правильно понял, что use-case такой: Вы переименовали файл с помощью функций вашего bash или другой плюшки операционной системы и хотите от среды контроля версий чтобы она догадалась что вон тот файл на самом деле не просто добавлен, а что он ничто иное как переименованная копия прежнего файла?
Нет, я отрефакторил проект (с помощью пятнадцати разных инструментов), что привело к радикальной смене его структуры, а теперь хочу это закоммитить.
Тогда думаю Упс. Все что Вы получите так это информация о том, что что-то добавлено или удалено. Возможно и ошибаюсь… Окончательного итога в этом поведении подводить не стану
Это я все к тому, что магическим
А жаль, да.
hg ci -A -m «Project file structure changed» не обойдешься.А жаль, да.
Почитайте на досуге про опцию --similarity команды addremove и будет Вам счастье (хотя возможно и не полное).
Вообще не счастье. При рефакторинге (когда файлы не только двигаются, но и правятся) ситуация очень быстро переходит в состояние «куча ложных срабатываний».
Так тут никакой всегда работающей автоматики и не может быть. Но --similarity значительную часть случаев окучивает автоматически, а остальное можно и ручками подправить. Хотя конечно правильнее было бы пользоваться средствами рефакторинга, непосредственно взаимодействующими с VCS.
Хотя конечно правильнее было бы пользоваться средствами рефакторинга, непосредственно взаимодействующими с VCS.
… и вот в этот момент мы понимаем, что дело уже не в используемой VCS, а в инструментах.
Git не сохраняет информацию о переименованиях. Так что либо после рефакторинга переименованные файлы достаточно схожи, либо будьте любезны иметь промежуточное изменение, содержащее только переименование файлов и ещё одно с собственно изменением содержимого.
Так что дело ещё и в VCS.
Так что дело ещё и в VCS.
(какая, все-таки, занимательная система этот ваш git)
Но вообще, создание промежуточных изменений в таком случае — как раз дело инструментов.
Но вообще, создание промежуточных изменений в таком случае — как раз дело инструментов.
Не видел реальных проектов с такими промежуточными изменениями. Обычно этот факт просто игнорируют, так как процент схожести достаточно высок, либо народу всё равно, так как они не знают, что проверка на переименования происходит каждый раз, когда вы запускаете нужную команду (log, diff) и то только если об этом действии попросить (или настроить соответствующий псевдоним). Только commit и merge делают это по‐умолчанию.
А git не мой, мне всегда больше нравился mercurial. В нём вы можете сделать «hg mv» и изменить всё содержимое. Только на этот раз придётся делать «hg mv» или явно запрашивать автоопределение (hg addremove --similarity), «hg log»/«hg diff» возможностью определения переименований не обладают.
А git не мой, мне всегда больше нравился mercurial. В нём вы можете сделать «hg mv» и изменить всё содержимое. Только на этот раз придётся делать «hg mv» или явно запрашивать автоопределение (hg addremove --similarity), «hg log»/«hg diff» возможностью определения переименований не обладают.
Git не сохраняет информацию о переименованиях.
ZyXI, вы тоже что-то путаете.
mkdir test
cd test
git init
echo -e "Line1\nLine2" > aaa
git add -A && git ci -m "Commit 1"
mv aaa bbb
echo -e "Line3" >> bbb
git add -A && git ci -m "Commit 2"
git log --follow bbb # фигурируют оба коммита
git blame bbb # фигурируют оба коммита
Ничего не путаю. Я же явно сказал — git можно попросить сделать автоопределение. Похоже, немного ошибся с тем, какие команды делают такое определение по умолчанию (не вспомнил про annotate).
Покажите то же самое, изменив файл полностью. Или явно указав не просто --follow, а «-M100%» (то есть, потребуйте полное сходство). Или просто возьмите исходники git и покажите, где данная информация сохраняется.
Покажите то же самое, изменив файл полностью. Или явно указав не просто --follow, а «-M100%» (то есть, потребуйте полное сходство). Или просто возьмите исходники git и покажите, где данная информация сохраняется.
Ну да, и именно поэтому у нас основной инструментарий состоит из консоли и текстового редактора. Я вообще не понимаю, в чем проблема с 'hg mv', которым я обычно и пользуюсь.
Я вообще не понимаю, в чем проблема с 'hg mv', которым я обычно и пользуюсь.
В количестве мелких операций?
По сравнению с «Ctrl-R-R на имени класса, ввел новое имя, получил полную замену по всему проекту и правильно поименованный файл» ручные операции все-таки дороже.
Я не говорю, что они невозможны; я просто констатирую факт, что это менее производительно.
Если у Вас все так автоматизировано, то тем более не должно быть проблемой написать в IDE макрос, выполняющий в нужный момент команду 'hg rm'. Если же нет, то следует вспомнить про старый совет — следить за используемыми инструментальными средствами и не попадать в зависимость от них.
hg ci -A, умеет ровно то что умеют add/remove по отдельности. Вот пример информации о переименовывании «AppErrors.hpp (renamed from src/Errors.hpp)»
Комментатор выше слегка ошибся. Rename в hg эквивалентен copy + remove, а не delete + add. Именно поэтому сохраняется история.
Про это не говорят, потому что это ложное преимущество. Хотя, не буду скрывать, очень удобное на первый взгляд.
Не бывает «своей версии в чистом виде», код — общий.
Если вы почитаете, например, Continuous Delivery, то вы поймете, что ваша проблема вызвана двумя вещами: недостаточным тестовым покрытием (которое сразу показало бы, где ошибка) и слишком редким обновлением своей версии.
Не бывает «своей версии в чистом виде», код — общий.
Если вы почитаете, например, Continuous Delivery, то вы поймете, что ваша проблема вызвана двумя вещами: недостаточным тестовым покрытием (которое сразу показало бы, где ошибка) и слишком редким обновлением своей версии.
Да это же вы неправильно бутерброд едите.
Даже если всё покрыто тестами, делая частые обновления во время недельного рефакторинга будете ловить чужие фейлы, которые отнимут время. Например, если у вас уже были красные тесты и пришли еще чужие — будешь как золушка крупу от гречки отделять. При этом на добавленный код вы не особо и рассчитывали.
Код общий, но версия кода разная. И правильно говорит ltwood — можно и иногда нужно сначала закоммитить улучшение той версии которую брали, и отдельно объединить с актуальной (возможно красной). Собственно так работает и svn merge, только в dvcs ветка — любая альтернативная история, создастся автоматически.
И да, в dvcs всегда есть выбор. Можно по-svnовски делать коммиты без бранчей как вы привыкли. Я вот чаще тоже так делаю если коммит не такой большой чтобы в случае конфликта все в нем же и поправить.
Даже если всё покрыто тестами, делая частые обновления во время недельного рефакторинга будете ловить чужие фейлы, которые отнимут время. Например, если у вас уже были красные тесты и пришли еще чужие — будешь как золушка крупу от гречки отделять. При этом на добавленный код вы не особо и рассчитывали.
Код общий, но версия кода разная. И правильно говорит ltwood — можно и иногда нужно сначала закоммитить улучшение той версии которую брали, и отдельно объединить с актуальной (возможно красной). Собственно так работает и svn merge, только в dvcs ветка — любая альтернативная история, создастся автоматически.
И да, в dvcs всегда есть выбор. Можно по-svnовски делать коммиты без бранчей как вы привыкли. Я вот чаще тоже так делаю если коммит не такой большой чтобы в случае конфликта все в нем же и поправить.
Да это же вы неправильно бутерброд едите.
Я его не ем, его авторы CD едят.
Даже если всё покрыто тестами, делая частые обновления во время недельного рефакторинга будете ловить чужие фейлы, которые отнимут время
А не надо делать недельный рефакторинг. Разбивайте задачи на короткие.
Например, если у вас уже были красные тесты и пришли еще чужие — будешь как золушка крупу от гречки отделять.
Так тоже делать не надо. Сначала добились зеленых тестов, потом взяли версию. Главное при этом помнить, что состояние «добились зеленых тестов» должно быть не реже раза в день.
Поймите, чем вы дальше от «основной ветки», тем дороже вам обойдется интеграция. Какими бы прекрасными не были средства слияния, семантические коллизии они ловят очень плохо.
И все же, что если в середине своей работы я обновляюсь и мне приходит чужой крэш?
Во-первых, не обновляйтесь в середине работы, обновляйтесь на гринбаре.
Во-вторых, это не чужой крэш (потому что в интеграционной ветке по определению не должно быть крэшей), это ваш крэш, потому что это ваш код несовместим с состоянием проекта. Соответственно, вам и надо его править.
Во-вторых, это не чужой крэш (потому что в интеграционной ветке по определению не должно быть крэшей), это ваш крэш, потому что это ваш код несовместим с состоянием проекта. Соответственно, вам и надо его править.
Не знаю как на вашей планете или у андроидов, но у землян:
— далеко не все покрыто тестами, встречаются чужие крэши при зеленом CI
— рефакторинг не каждого говна можно разбить на задачи по <8ч
— человек не совершенен: ленив, глуп (починит тест, а не проблему) и болезнен (рефакторил 2часа, но с перерывом в неделю)
— кофе недешев, а время тестов нельзя ускорить до секунды, поэтому разоришься на кофе и журналах прогоняя все тесты перед каждым коммитом, плюс не сможешь работать с кодом пока он проверяется локально
У нас сейчас только минимально-необходимые тесты проходят за 20 минут. А все (параллельно) за часа 4.
— далеко не все покрыто тестами, встречаются чужие крэши при зеленом CI
— рефакторинг не каждого говна можно разбить на задачи по <8ч
— человек не совершенен: ленив, глуп (починит тест, а не проблему) и болезнен (рефакторил 2часа, но с перерывом в неделю)
— кофе недешев, а время тестов нельзя ускорить до секунды, поэтому разоришься на кофе и журналах прогоняя все тесты перед каждым коммитом, плюс не сможешь работать с кодом пока он проверяется локально
У нас сейчас только минимально-необходимые тесты проходят за 20 минут. А все (параллельно) за часа 4.
Ну так вы Continuous Delivery-то почитайте, там как раз все эти проблемы рассматриваются. А конкретная проблема со временем тестов — и не только там. Если минимально необходимые тесты проходят 20 минут, то вы что-то делаете не так.
Не бывает чужих крэшей. Бывает неработающий проект, который надо чинить.
А нужно. Я раньше тоже так думал, а теперь почему-то удается. Рефакторинг — это вообще набор очень маленьких и очень понятных шагов, просто не надо их перепрыгивать.
Ну так это, переходите на те системы, где коммит-тесты гонются не локально, а на билд-гриде; решите тем самым обе ваших проблемы.
встречаются чужие крэши
Не бывает чужих крэшей. Бывает неработающий проект, который надо чинить.
рефакторинг не каждого говна можно разбить на задачи по <8ч,
А нужно. Я раньше тоже так думал, а теперь почему-то удается. Рефакторинг — это вообще набор очень маленьких и очень понятных шагов, просто не надо их перепрыгивать.
разоришься на кофе и журналах прогоняя все тесты перед каждым коммитом, плюс не сможешь работать с кодом пока он проверяется локально
Ну так это, переходите на те системы, где коммит-тесты гонются не локально, а на билд-гриде; решите тем самым обе ваших проблемы.
Вообще мы что, про DVCS оба говорим, или вы защищаете svn? Не понимаю как в последней проверять коммиты удаленно, не позволяя фейлам проникать «в интеграционную ветку в которой по определению не должно быть крэшей».
Конечно кто-то должен чинить крэши, только в это время другие не должны стопориться из-за того что по вашему совету они чаще обновляются, от лукавого.
Про «что-то делаем не так» я воздержусь, чтобы не нарушить идилию вашей планеты с розой и недействующим вулканом ;) Не удивлен что у вас единый, независимый от величины и особенностей проекта, временной критерий «так».
Конечно кто-то должен чинить крэши, только в это время другие не должны стопориться из-за того что по вашему совету они чаще обновляются, от лукавого.
Про «что-то делаем не так» я воздержусь, чтобы не нарушить идилию вашей планеты с розой и недействующим вулканом ;) Не удивлен что у вас единый, независимый от величины и особенностей проекта, временной критерий «так».
Вообще мы что, про DVCS оба говорим, или вы защищаете svn?
Я защищаю «правильный» подход. А тип VCS никакого значения не имеет.
(и нет, я не пользуюсь SVN)
Конечно кто-то должен чинить крэши, только в это время другие не должны стопориться из-за того что по вашему совету они чаще обновляются, от лукавого.
Поэтому крэши не должны проникать туда, откуда все обновляются.
А если обновляться редко, то стоимость мержа увеличивается.
Не удивлен что у вас единый, независимый от величины и особенностей проекта, временной критерий «так».
Он не у меня, он у Хамбла/Фарли и сторонников TDD. BVT должны проходить достаточно быстро, чтобы их можно было гонять перед каждым коммитом, иначе они теряют смысл.
Я ожидал, что мне скажут, что в SVN мне просто надо было вовремя создавать ветку, но про тесты не ожидал, да.
1. Хотел бы я жить во вселенная, в которой в реальных проектах есть нетривиальные тесты с ненулевым покрытием. В моем мире как раз та функциональность, на которую тратится 99% времени, тестами покрывается с большим трудом. Потому что
— она очень сильно завязана на обрабатываемые данные;
— автоматическая проверка корректности результатов тестов — задача, сравнимая по сложности с разработкой самого приложения.
(Если что, то область — промышленные системы обработки сигналов.) Ну и само выполнение реверсивных тестов часто может занимать несколько суток.
2. Хотелось бы, чтобы была возможность зафиксировать в репозитории любое состояние кода, независимо от того, подумал ли я вовремя о том, что «тут надо бы создать ветку».
1. Хотел бы я жить во вселенная, в которой в реальных проектах есть нетривиальные тесты с ненулевым покрытием. В моем мире как раз та функциональность, на которую тратится 99% времени, тестами покрывается с большим трудом. Потому что
— она очень сильно завязана на обрабатываемые данные;
— автоматическая проверка корректности результатов тестов — задача, сравнимая по сложности с разработкой самого приложения.
(Если что, то область — промышленные системы обработки сигналов.) Ну и само выполнение реверсивных тестов часто может занимать несколько суток.
2. Хотелось бы, чтобы была возможность зафиксировать в репозитории любое состояние кода, независимо от того, подумал ли я вовремя о том, что «тут надо бы создать ветку».
Хотелось бы, чтобы была возможность зафиксировать в репозитории любое состояние кода, независимо от того, подумал ли я вовремя о том, что «тут надо бы создать ветку».
Это называется «хочу бесконечное undo».
И, это, несомненно, очень круто и приятно (я тоже хочу). Но вот вашей проблемы с «внезапно пришел общий код, который все ломает» не решает.
Версия, полученная после выполнения некоей модификации, отличается от версии, полученной после вливания в нее других изменений. То, что при использовании VCS история (все версии) должна сохраняться вся и без изменений, для меня является как бы аксиомой. Так что разговоры про бесконечный undo и ссылка на тесты как на средство для преодоления такого фатального несовершенства VCS выглядит для меня как обоснование пользы от костылей.
То, что при использовании VCS история (все версии) должна сохраняться вся и без изменений, для меня является как бы аксиомой.
Тут вопрос только в том, что считать версией. Если довести ваш подход до абсолюта, то VCS должна хранить каждый введенный вами символ (ну или по крайней мере, каждое сохранение файла).
Но в разработческих проектах так не делают, потому что (в идеале) любой срез состояния VCS должен быть полностью консистентным. Эту (идеологическую) проблему решают тем, что создают ветки, которые могут быть неконсистентными (или должны быть консистентны внутри себя, без оглядки на общее состояние проекта). И это тоже не новость, это придумали радикально до DVCS, и у этого подхода есть фундаментальная проблема (которая, собственно, описана в нежно мной любимом Continuous Delivery) — чем дольше код варится в своей ветке, тем сложнее его интегрировать.
Соответственно, достоинство hg (перед svn) в вашем примере в том, что он создает вам ветку бесплатно и прозрачно (я понимаю, что это упрощение). Но если вы рассматриваете любые долгоживущие ветки как зло, это же достоинство превращается в недостаток.
достоинство hg (перед svn) в вашем примере в том, что он создает вам ветку бесплатно и прозрачно
Да, в такой формулировке я соглашусь с Вами. Ну и как бы мне такое поведение теперь кажется обязательным для любой VCS.
Тут вопрос только в том, что считать версией.
В реальной жизни ответ мне кажется банальным. Версия — это то, к чему не поленились написать комментарий :)
Да, в такой формулировке я соглашусь с Вами. Ну и как бы мне такое поведение теперь кажется обязательным для любой VCS.
Тут вопрос только в том, что считать версией.
В реальной жизни ответ мне кажется банальным. Версия — это то, к чему не поленились написать комментарий :)
В реальной жизни ответ мне кажется банальным. Версия — это то, к чему не поленились написать комментарий :)
Это было бы смешно, если бы не было грустно.
Во-первых, в реальной жизни разработчиков приходится заставлять (в том числе хуками) писать комментарии.
А во-вторых, что же делать с консистентностью кода?
в реальной жизни разработчиков приходится заставлять (в том числе хуками) писать комментарии
Судя по моему опыту это полностью определяется традициями в команде. У нас все пишут более или менее подробные комментарии, а коммитов без комментариев я вообще не видел ни разу.
что же делать с консистентностью кода?
А что с ней можно сделать, если выполнение полного реверсивного теста занимает несколько суток, и к тому же результаты тестов почти никогда нельзя проверить автоматически? У нас полностью эквивалентных изменений вообще не бывает, любое тривиальное шевеление кода слегка меняет результаты (потому что сплошь вещественные числа и нетривиальная математика), а сделать автоматическую проверку корректности результатов — та еще задача, сравнимая по сложности с решаемой. Область, где можно писать быстро работающие тесты с однозначной проверкой корректности выглядит для меня то ли как рай, то ли как детский сад :)
Судя по моему опыту это полностью определяется традициями в команде. У нас все пишут более или менее подробные комментарии, а коммитов без комментариев я вообще не видел ни разу.
что же делать с консистентностью кода?
А что с ней можно сделать, если выполнение полного реверсивного теста занимает несколько суток, и к тому же результаты тестов почти никогда нельзя проверить автоматически? У нас полностью эквивалентных изменений вообще не бывает, любое тривиальное шевеление кода слегка меняет результаты (потому что сплошь вещественные числа и нетривиальная математика), а сделать автоматическую проверку корректности результатов — та еще задача, сравнимая по сложности с решаемой. Область, где можно писать быстро работающие тесты с однозначной проверкой корректности выглядит для меня то ли как рай, то ли как детский сад :)
Судя по моему опыту это полностью определяется традициями в команде.
То же самое можно сказать, например, про юнит-тесты.
А что с ней можно сделать, если выполнение полного реверсивного теста занимает несколько суток, и к тому же результаты тестов почти никогда нельзя проверить автоматически?
Я, вообще-то, не тесты имел в виду.
Область, где можно писать быстро работающие тесты с однозначной проверкой корректности выглядит для меня то ли как рай, то ли как детский сад
Ну, видимо, добрая половина нынешних методик программирования (TDD, CI, CD) рождены то ли в раю, то ли в детском саду. А воспитателями там, видимо, Бек и Мезарос.
PS
У нас полностью эквивалентных изменений вообще не бывает
Это значит, что у вас не бывает рефакторинга. Вообще.
То же самое можно сказать, например, про юнит-тесты.
Не вполне.Смыть за собой в туалете Написать комментарий к коммиту можно всегда, а юнит-тесты имеют хорошо известные ограничения (в том числе и описанные в трудах тех самых воспитателей из детсада).
добрая половина нынешних методик программирования (TDD, CI, CD) рождены то ли в раю, то ли в детском саду
К счастью далеко не добрая половина, иначе за пределами тех областей, где формальные тесты применимы, вообще не было бы жизни.
Это значит, что у вас не бывает рефакторинга. Вообще.
Рефакторинга с трогом смысле (такого, после которого все тесты горят зеленым) — да, не бывает. Адепты часто не хотят понимать, что области бывают разные и их любимые методики применимы не повсеместно. Все численное программирование оказывается чрезвычайно неудобной областью для формальных тестов. Тесты практически всегда, почти при любых изменениях загораются красным и приходится смотреть на результаты глазками и решать, что произошло — фигня или epic fail. Да, делались попытки писать умные тесты, но оказалось, что получается очень дорого, долго и в целом неэффективно.
Не вполне.
добрая половина нынешних методик программирования (TDD, CI, CD) рождены то ли в раю, то ли в детском саду
К счастью далеко не добрая половина, иначе за пределами тех областей, где формальные тесты применимы, вообще не было бы жизни.
Это значит, что у вас не бывает рефакторинга. Вообще.
Рефакторинга с трогом смысле (такого, после которого все тесты горят зеленым) — да, не бывает. Адепты часто не хотят понимать, что области бывают разные и их любимые методики применимы не повсеместно. Все численное программирование оказывается чрезвычайно неудобной областью для формальных тестов. Тесты практически всегда, почти при любых изменениях загораются красным и приходится смотреть на результаты глазками и решать, что произошло — фигня или epic fail. Да, делались попытки писать умные тесты, но оказалось, что получается очень дорого, долго и в целом неэффективно.
Не вполне. Написать комментарий к коммиту можно всегда,
Ага. «Фикс». Сколько раз видел.
Адепты часто не хотят понимать, что области бывают разные и их любимые методики применимы не повсеместно
… а все остальные считают, что если методика не взлетела с первого подхода, то она неприменима.
Нет, я не говорю, что она заведомо применима. Но ваша убежденность, что все области, где она (методика) применима, рай или детский сад, меня все-таки удивляет.
lair, ваши пишут «Fix» потому что вы заставляете (в том числе хуками) писать комментарии ;)
Да я-то за 20 лет практики видел и репозитории вообще без комментариев к ревизиям. Но культура аккуратного описания выполненных модификаций прививается очень быстро, если сделать такую практику банально неодобряемой. У меня все пишут очень аккуратно и подробно, без всяких хуков.
если методика не взлетела с первого подхода, то она неприменима
Вполне применима в своей области применимости. Более того, я ее успешно применял, когда меня заносило в «райские» области (я, кстати, это слово в положительном смысле использовал). Но во многих областях она, если и не неприменима, то очень трудозатратна и там есть другие методики, которые не сильно хуже, хотя и не так раскручены. Но большинство примеров из книжек как раз относятся к категории детского сада, да.
если методика не взлетела с первого подхода, то она неприменима
Вполне применима в своей области применимости. Более того, я ее успешно применял, когда меня заносило в «райские» области (я, кстати, это слово в положительном смысле использовал). Но во многих областях она, если и не неприменима, то очень трудозатратна и там есть другие методики, которые не сильно хуже, хотя и не так раскручены. Но большинство примеров из книжек как раз относятся к категории детского сада, да.
Мне кажется диалога у вас не получится, так как ваш подход прагматический и основанный на опыте, а товарищ lair исходит из соображений религиозной чистоты и апеллирует к авторитетам церкви методологии. :)
Вы так говорите, будто точно знаете все о моем опыте.
Не знаю. Но ваш подход мне кажется крайне не прагматическим и оторванным от реальности. Мой опыт говорит, что все попытки слепо следовать букве методологии не считаясь с реальными условиями — заканчивались грустно. И работают методологии точно как завещали отцы-основатели или в сферической вакуумной разработке (со сферическими девелоперами и менеджерами) или в очень узкой предметной области под которую методология писалась. Например, священная корова многих методологий — это высокое покрытие кода автоматическими тестами. На практике есть куча областей, где это не возможно или не целесообразно.
Но ваш подход мне кажется крайне не прагматическим и оторванным от реальности.
Какой именно? «Интегрируйтесь часто»?
Например, священная корова многих методологий — это высокое покрытие кода автоматическими тестами. На практике есть куча областей, где это не возможно или не целесообразно.
Я с удовольствием прочитаю книгу или хотя бы статью по любой современной методологии, которая пропагандирует и аргументирует отказ от автоматического тестирования.
Посоветуете что-нибудь?
Какой именно?
Фанатичное следование канонам методологии.
Я с удовольствием прочитаю книгу или хотя бы статью по любой современной методологии, которая пропагандирует и аргументирует отказ от автоматического тестирования.
Во-во, я выше как раз про это говорю.
Книжки это хорошо, но книжек никак? Своя голова на плечах — тоже неплохой инструмент.
Вот вы говорите, что не знаете методологию без автоматических тестов, и авторитетные книжки по этому поводу молчат. Как же тогда вы будите организовывать работу если вам нужно будет сделать это в предметной области, где такие тесты сделать невозможно?
Фанатичное следование канонам методологии.
Это не мой подход, а то, что вы мне приписываете.
Как же тогда вы будите организовывать работу если вам нужно будет сделать это в предметной области, где такие тесты сделать невозможно?
Приведите пример.
Вы серьёзно думаете, что таких областей нету или их мало? Вот выше ltwood приводил пример из своей области. У меня куча примеров из своей (симуляции и игры) — например как тестировать выход графической подсистемы, где очень многие проблемы можно определить только визуально — например артефакты изображения, мерцания, ФПС просидающий только в определенных ситуациях и т.д. Или например алгоритмы ИИ, которые недетерминированные by design. И таким областей очень много. Программирование каким-нибудь «java-enterprise» далеко не ограничивается.
Вы серьёзно думаете, что таких областей нету или их мало?
Нет, я серьезно прошу примеров.
например как тестировать выход графической подсистемы, где очень многие проблемы можно определить только визуально — например артефакты изображения, мерцания, ФПС просидающий только в определенных ситуациях и т.д.
FPS можно замерять программно (и это не отличается от других тестов на производительность). С остальным сложнее, да. Но вообще, это описано: c2.com/cgi/wiki?TestingGraphicsSystems
Так что это как раз рассуждение из области «как тестировать presentation layer», оно многократно обжевано.
Или например алгоритмы ИИ, которые недетерминированные by design.
Эмм. Мне казалось, что алгоритмы ИИ, несмотря на свою недетерминированность, должны обладать некими конкретными характеристиками (ради которых их и разрабатывают). Я не прав?
В вики они никаких толковых решений не предлагают. Попиксельное сравнение? Это смешно.
У ИИ в играх и симуляциях цель обычно чтоб было «естественно» и чтоб игрокам было интересно. Вот требование «естественности» и вносит огромное количество недетерминированности, так как самое неестественно что есть — это ИИ который всегда ведет себя одинаково. Даже в самом простом варианте — ИИ настольных играх в часто вносится элемент случайности, что бы имея похожие по оценке варианты хода, ИИ не вел себя предсказуемо и скучно. Но если в настольных играх этот элемент случайности можно например отключить, то сложных системах, с fuzzy logic, нейронными сетями и обучающимся алгоритмами в общем случае это будет сделать невозможно.
Вообще спор пустой получается. Я и другие люди привели вам примеры, но если вы все равно предпочитаете жить в сказке, где любую софтверную систему можно на 95% покрыть автоматическими тестами, и любая разработка может быть построена в точном соответствие с модными методологиями — то я вряд ли смогу вас в этом разубедить, тем более что конкретные примеры вас не убеждают.
У ИИ в играх и симуляциях цель обычно чтоб было «естественно» и чтоб игрокам было интересно. Вот требование «естественности» и вносит огромное количество недетерминированности, так как самое неестественно что есть — это ИИ который всегда ведет себя одинаково. Даже в самом простом варианте — ИИ настольных играх в часто вносится элемент случайности, что бы имея похожие по оценке варианты хода, ИИ не вел себя предсказуемо и скучно. Но если в настольных играх этот элемент случайности можно например отключить, то сложных системах, с fuzzy logic, нейронными сетями и обучающимся алгоритмами в общем случае это будет сделать невозможно.
Вообще спор пустой получается. Я и другие люди привели вам примеры, но если вы все равно предпочитаете жить в сказке, где любую софтверную систему можно на 95% покрыть автоматическими тестами, и любая разработка может быть построена в точном соответствие с модными методологиями — то я вряд ли смогу вас в этом разубедить, тем более что конкретные примеры вас не убеждают.
Да нет. Мне просто интересно, как люди разрабатывают и, самое главное, тестируют системы из вашей категории.
И отдельно мне интересно, не написано ли по этому поводу чего-нибудь интересного, чтобы вас вопросами не донимать.
И отдельно мне интересно, не написано ли по этому поводу чего-нибудь интересного, чтобы вас вопросами не донимать.
Так же, как тестировали и до изобретения TDD. Это классная штука, и всё такое, но не серебрянная пуля. И я сталкиваюсь при разработке графической части игры ровно с теми же вопросами, что и Zigmar
А можно поподробнее, «так же» — это как? Вот возьмем обычное — пользователь игры пишет «у меня возникает прозрачная стена в этой точке карты если смотреть туда». Как это тестируют? Исключительно ручным прогоном?
(я, заметим, нигде не говорю, что TDD — это серебряная пуля; я вообще не призываю его использовать)
(я, заметим, нигде не говорю, что TDD — это серебряная пуля; я вообще не призываю его использовать)
Коротко — да.
Подробно: Для тестирования создаются свои тестпланы: Пройти уровень на определенном уровне сложности, добившись определенных результатов. Если у игры есть еще и экономическая модель — то и под разные настройки тоже делают прогон.
Отдел тестеров обычно много раз проходит игру по разным сценариям. На выходе отчет определенного вида. Может сейчас что-то новое придумали, но года так до 2005 было именно так.
Подробно: Для тестирования создаются свои тестпланы: Пройти уровень на определенном уровне сложности, добившись определенных результатов. Если у игры есть еще и экономическая модель — то и под разные настройки тоже делают прогон.
Отдел тестеров обычно много раз проходит игру по разным сценариям. На выходе отчет определенного вида. Может сейчас что-то новое придумали, но года так до 2005 было именно так.
В основном пользуемся набором реверсивных тестов. При этом мы всегда готовы к тому, что тест в результате тривиальных на вид изменений может завершиться неудачно и придется смотреть на результаты глазками и (если на вид все нормально) обновлять критерии проверки корректности.
Ну и еще сильно помогает design by contract, массированная проверка assert-ов для всех мыслимых и немыслимых вариантов.
Ну и еще сильно помогает design by contract, массированная проверка assert-ов для всех мыслимых и немыслимых вариантов.
Что такое «реверсивный тест»?
Что мешает покрыть контракты тестами (в том числе автоматически)?
Ну и еще сильно помогает design by contract, массированная проверка assert-ов для всех мыслимых и немыслимых вариантов.
Что мешает покрыть контракты тестами (в том числе автоматически)?
Реверсивный тест — классическая методология тестирования, позволяющая убедиться в отсутствии регрессии. Для некоей версии, которую мы считаем корректной, сохраняем результаты выполнения на тестовых данных в качестве эталонных, а для последующих версий сравниваем (более или менее сложным алгоритмом сравнения) результаты выполнения с сохраненными эталонными результатами. Если результаты отличаются, то анализируем их вручную, убеждаемся в отсутствии регрессии и обновляем эталонные результаты.
Что мешает покрыть контракты тестами (в том числе автоматически)?
В основном ничего не мешает, но проверка контракта в живом приложении обычно оказывается более полезной. Покрытие тестами подразумевает наличие достаточно полного набора тест-кейсов, а проверка контрактов в живом приложении позволяет получать информативный фидбэк от тестеров, проводящих тестирование на стороне заказчика. Анализируя получаемые при этом исходные данные ошибочных прогонов иногда удается включить их в свою внутреннюю батарею тестов, но при этом приходится все время следить за тем, чтобы внутренние тесты не выполнялись слишком долго. Так что в основном все же используются очень ограниченные, но быстрые реверсивные тесты и относительно редко запускается внутренний тест на полной батарее тестов.
Что мешает покрыть контракты тестами (в том числе автоматически)?
В основном ничего не мешает, но проверка контракта в живом приложении обычно оказывается более полезной. Покрытие тестами подразумевает наличие достаточно полного набора тест-кейсов, а проверка контрактов в живом приложении позволяет получать информативный фидбэк от тестеров, проводящих тестирование на стороне заказчика. Анализируя получаемые при этом исходные данные ошибочных прогонов иногда удается включить их в свою внутреннюю батарею тестов, но при этом приходится все время следить за тем, чтобы внутренние тесты не выполнялись слишком долго. Так что в основном все же используются очень ограниченные, но быстрые реверсивные тесты и относительно редко запускается внутренний тест на полной батарее тестов.
Реверсивный тест — классическая методология тестирования, позволяющая убедиться в отсутствии регрессии. Для некоей версии, которую мы считаем корректной, сохраняем результаты выполнения на тестовых данных в качестве эталонных, а для последующих версий сравниваем (более или менее сложным алгоритмом сравнения) результаты выполнения с сохраненными эталонными результатами.
Может, все-таки, регрессионный? Я честно поискал в яндексе термин — ничего (из области программирования) не нашел.
Покрытие тестами подразумевает наличие достаточно полного набора тест-кейсов, а проверка контрактов в живом приложении позволяет получать информативный фидбэк от тестеров, проводящих тестирование на стороне заказчика.
Ну то есть по сути, вы перенесли функцию тестирования с себя на тестировщиков на стороне заказчика.
Очень выгодное проектное решение; жаль, не все заказчики на него согласны.
Может, все-таки, регрессионный?
Это синонимы. Просто я очень давно учился :)
Заказчика интересует полная стоимость предлагаемого решения. По моему опыту итерационное накопление получаемых от заказчика тестовый кейсов существенно уменьшает суммарную стоимость. Я уже не говорю о том, что полное тестирование на нашей стороне может быть вообще невозможным, поскольку в реальной жизни все время вплоть до завершения проекта только заказчик обладает полным пониманием того, что следует считать ошибкой. При этом заказчика вполне устраивает, если мы на своей стороне выявляем все ошибки, которые раньше встречались и были описаны и переданы нам (т.е. покрыты нашей батареей тестов).
Это синонимы. Просто я очень давно учился :)
Заказчика интересует полная стоимость предлагаемого решения. По моему опыту итерационное накопление получаемых от заказчика тестовый кейсов существенно уменьшает суммарную стоимость. Я уже не говорю о том, что полное тестирование на нашей стороне может быть вообще невозможным, поскольку в реальной жизни все время вплоть до завершения проекта только заказчик обладает полным пониманием того, что следует считать ошибкой. При этом заказчика вполне устраивает, если мы на своей стороне выявляем все ошибки, которые раньше встречались и были описаны и переданы нам (т.е. покрыты нашей батареей тестов).
Да, религиозную точку зрения вообще трудно оспорить, она самодоказательная.
>>значит комманду (и вас) он или устраивает
Ну не то чтобы устраивает… но Вы сами понимаете что не все так просто. Ведь переход на что-то новое это же не просто взял и насетапил ) Это еще и договориться о новых стандартных схемах использования. Более того всегда кто-то за, а кто-то против и этих «динозавров» надо «уговаривать» или учить навыкам работы. А иногда просто между версиями до след. релиза слишком мало времени. Вобщем переход с одного на другое занимает определенное человеко-время )
Мне кажется что создавая этот опрос Вы хотели знать ответ на вопрос «А сколько реально коммерческих продуктов создается тем или иным средством?». Только вот не учли, что программер может и дома программить зарабатывая себе на хлебушек. Более того несмотря на тот факт, что программер может добросовестно относиться к работе и делать достаточно много для компании где работает днем, ему тем не менее никто не мешает сделать куда больше коммитов в какой-нить open-source проект дома.
Схем взаимодействий между программерами очень и очень много и говорить «выбирай чтото одно», а потом на основании этой статистики по сделанным выборам что-то оценивать, на мой взгляд не очень корректно
Ну не то чтобы устраивает… но Вы сами понимаете что не все так просто. Ведь переход на что-то новое это же не просто взял и насетапил ) Это еще и договориться о новых стандартных схемах использования. Более того всегда кто-то за, а кто-то против и этих «динозавров» надо «уговаривать» или учить навыкам работы. А иногда просто между версиями до след. релиза слишком мало времени. Вобщем переход с одного на другое занимает определенное человеко-время )
Мне кажется что создавая этот опрос Вы хотели знать ответ на вопрос «А сколько реально коммерческих продуктов создается тем или иным средством?». Только вот не учли, что программер может и дома программить зарабатывая себе на хлебушек. Более того несмотря на тот факт, что программер может добросовестно относиться к работе и делать достаточно много для компании где работает днем, ему тем не менее никто не мешает сделать куда больше коммитов в какой-нить open-source проект дома.
Схем взаимодействий между программерами очень и очень много и говорить «выбирай чтото одно», а потом на основании этой статистики по сделанным выборам что-то оценивать, на мой взгляд не очень корректно
Мне кажется что создавая этот опрос Вы хотели знать ответ на вопрос «А сколько реально коммерческих продуктов создается тем или иным средством?».
Отчасти согласен. Но то что 90% дома dvcs эксперты вовсе не значит, что они перешли на него (заставили перейти других) в офисе, где большинство проектов и печется. Задай вопрос иначе — «что вам нравится» — git и hg всех побил бы с большим отрывом еще год-два назад. А интересно реальное использование, чем сегодня приходится работать чаще.
Множественный выбор мне кажется также не выявит тенденции. У каждого есть скелет в шкафу — старый проект в который лезут так редко (но лезут) что переходить на другую vcs понятно не станут, а галочку поставят.
десяток лет наработок, более-менее активно используемых
обвязка из кучи рабочих скриптов с лохматых годов, разбираться в которых нет времени потому что надо поддерживать и оптимизировать прочую структуру
и сакраментальное — «работает- не тронь»
обвязка из кучи рабочих скриптов с лохматых годов, разбираться в которых нет времени потому что надо поддерживать и оптимизировать прочую структуру
и сакраментальное — «работает- не тронь»
В своих проектах — Git, на работе — Hg. Пользуясь и тем и этим, голосую за Git.
На работе даже новые модули используют CVS. Это огорчает.
вылезает боковая панель навигации и не дает отметить нужный пункт.
на работе — svn ( ретрограды, да )
свои проекты — mercurial ( bitbucket, перешел с ассемблы )
гит использую для скачивания сторонних библиотек (так уж вышло, что весь актуальный опенсорц — там)
на работе — svn ( ретрограды, да )
свои проекты — mercurial ( bitbucket, перешел с ассемблы )
гит использую для скачивания сторонних библиотек (так уж вышло, что весь актуальный опенсорц — там)
НЛО прилетело и опубликовало эту надпись здесь
TFS как система контроля версий или как система управления проектами? Можно bridge к git поставить.
НЛО прилетело и опубликовало эту надпись здесь
Если я ничего не путаю, то можно поставить git-tfs без необходимости менять саму VCS. Что-то типа фасада =)
Не путаете. Но есть особенности.
НЛО прилетело и опубликовало эту надпись здесь
Ну мне нравится git, но управление проектом, билды и тд — мне очень нравится в tfs. Tfs с git вместо встроенной vcs был бы просто шикарен. Но пока что так. Может разродятся, судя по тому что на кодплексе уже продавили git и hg.
НЛО прилетело и опубликовало эту надпись здесь
Git-tfs — обертка.
Вот ссылка на git tf.
Вот примеры сценариев:
С чекином можно связать WorkItem.
Я сейчас примерно так работаю в bazaar, но возможно попробую связку с git. Тогда доложу о результатах.
Вот примеры сценариев:
1. git tf clone myserver:8080/tfs $/TeamProjectA/Main
2. Make changes to the file in the Git repo
3. git commit -a -m «commit one» (commit changes locally)
4. Make more changes
5. git commit -a -m «commit two»
6. git tf pull --rebase
7. git tf checkin
С чекином можно связать WorkItem.
Я сейчас примерно так работаю в bazaar, но возможно попробую связку с git. Тогда доложу о результатах.
В своих проектах Git, на работе SharePoint.
В своих Git. На работе сейчас приходится использовать SVN — доступ к коду имеют не инженеры, а их некому переучивать.
А чем обусловлен такой порядок расположения? По дате появления?
Проголосовал за Git ибо его чаще пользую. Но вообще еще пользую Mercurial и Bazaar.
Проголосовал за Git ибо его чаще пользую. Но вообще еще пользую Mercurial и Bazaar.
Возможно, для удобного сравнения я просто не меняю порядок из первого опроса belonesox
НЛО прилетело и опубликовало эту надпись здесь
К сожалению перфорс. Лично мне он кажется ужасным. Может не привык еще за полгода, но сам подход, что система контроля версий может не знать о состоянии файлов на жестком диске, удручает.
GIT/SVN/TFS
на трех проектах по-разному.
больше всех полюбился GIT.
на трех проектах по-разному.
больше всех полюбился GIT.
На работе svn, для своих проектов mercurial (причем «центральное» хранилище разместил на dropbox, очень удобно)
Центральное это как? Вроде же в нем на каждый проект свой репозиторий (или даже несколько: dev, stable и т.д.).
Я недавно начал использовать mercurial (и вообще системы управления версиями) для своих проектов, читал только hginit.com и немного гугла.
Я недавно начал использовать mercurial (и вообще системы управления версиями) для своих проектов, читал только hginit.com и немного гугла.
«Центральное» в смысле то, которое для обмена между рабочими. Архитектура получается простая, в чем-то похожая на svn: на все компах — рабочие репозитории, в dropbox — репозиторий для синхронизации. Перед началом работы делаешь pull + update, по оконачании — commit + push в этот обменный репозиторий.
К проектам это отношения не имеет, но конечно для каждого проекта или группы связанных проектов удобнее иметь свой репозиторий.
К проектам это отношения не имеет, но конечно для каждого проекта или группы связанных проектов удобнее иметь свой репозиторий.
Дропбокс же не лочит все файлы перед синхрониацией — ему не надо. Значит есть вероятность что при одновременном push он возьмет и соединит две версии служебных git/hg файлов так, как ему вздумается, и истории придет конец. Это всё обсуждалось уже.
А почему не bitbucket?
MS Team Foundation Server забыли. в последней редакции 2012 бесплатен для команд из 5 разработчиков + при купленном MS Visual Studio на каждый серийный номер студии — + одна лицензия на этот же TFS, если я правильно понял.
из плюсов — нативно поддерживается студией, в том числе и эспресс версиями 2012.
из плюсов — нативно поддерживается студией, в том числе и эспресс версиями 2012.
SVN в своих проектах по привычке, хотя GIT попробовать хочется, но всё руки не доходят. На работе тоже SVN но там не я правила устанавливаю.
Ого! Неужели в этом году Git наконец-то обойдёт SVN?
На работе недавно перешли с svn на git. Так что в этот раз голос уже за git.
в данный момент svn
два месяца назад — hg
два месяца назад — hg
Лично я для проекта над которым работаю один — использую SVN. На работе — Git.
О_о
Ничего не перепутали? Может наоборот?
Ничего не перепутали? Может наоборот?
Нормальная ситуация. Когда ты сидишь один, тебе важна только твоя история и централизация на определенном сервере.
Гит больше подходит для многопользовательских разработок.
Гит больше подходит для многопользовательских разработок.
Нормальная ситуация. Когда ты сидишь один, тебе важна только твоя история и централизация на определенном сервере.
Глупость какая-то. Как раз чтобы работать одному Гит однозначно удобнее. Тебе не нужен сервер, не нужна сеть для коммита. Ты просто сделал
git init — и всё, репа готова. А в СВН нужен центральный репозиторий. Если упадёт сеть — остались без коммитов. Короче сплошные костыли. Не понимаю людей, которые используют СВН для одиночной разработки. Это изврат ведь.Парирую.
Во-первых, сеть сейчас — это довольно стабильная вещь. И всегда можно найти альтернативу. Для личных проектов время — не самый критичный параметр, потому подождать полчаса, пока провайдер перезагружает хаб, всегда можно.
Во-вторых, если разработчик для своих целей может использовать несколько рабочих мест, локальный репозиторий — как мертвому припарка. Если вечно комиттить в мастер получаем тот же SVN, но с двумя действиями для коммита вместо одного.
У меня есть:
— основной стационарный домашний компьютер;
— ноутбук, которым я пользуюсь только тогда, когда жене срочно и надолго потребовался копьютер;
— рабочий стационарник, где я после работы могу поковырять свои игрушки.
— на всех машинах вечный интернет.
— нежелание носить ноут и пользоваться маленькими экранами.
Какие преимущества даст мне гит, либо что-то подобное, кроме возвышения моей персоны в Ваших глазах?
Во-первых, сеть сейчас — это довольно стабильная вещь. И всегда можно найти альтернативу. Для личных проектов время — не самый критичный параметр, потому подождать полчаса, пока провайдер перезагружает хаб, всегда можно.
Во-вторых, если разработчик для своих целей может использовать несколько рабочих мест, локальный репозиторий — как мертвому припарка. Если вечно комиттить в мастер получаем тот же SVN, но с двумя действиями для коммита вместо одного.
У меня есть:
— основной стационарный домашний компьютер;
— ноутбук, которым я пользуюсь только тогда, когда жене срочно и надолго потребовался копьютер;
— рабочий стационарник, где я после работы могу поковырять свои игрушки.
— на всех машинах вечный интернет.
— нежелание носить ноут и пользоваться маленькими экранами.
Какие преимущества даст мне гит, либо что-то подобное, кроме возвышения моей персоны в Ваших глазах?
— Подождать полчаса перед коммитом, нет, даже перед svn diff — но ведь мазохизм же :)
— Два действия вместо одного — ерунда. Всегда можно написать алиас (вплоть до svn ci / svn up) который будет коммитить и сразу отправлять. Наоборот, когда можно делать и так, и сяк — это преимущество.
— держать свой svn сервер, когда есть bitbucket/github неудобно, последние предоставляют еще и удобный визуализатор, да и бэкап будет (если subversion сервер навернется — история пропадет, в чекауте она не хранится).
— (редко, но) муторно заводить новый репозиотрий в svn, в то время как «git init» делается где/когда угодно, и позволяет работать локально столько долго сколько потребуется, и потом «централизировать» тоже за пару команд (ну и создания новой репы на битбакете)
— Два действия вместо одного — ерунда. Всегда можно написать алиас (вплоть до svn ci / svn up) который будет коммитить и сразу отправлять. Наоборот, когда можно делать и так, и сяк — это преимущество.
— держать свой svn сервер, когда есть bitbucket/github неудобно, последние предоставляют еще и удобный визуализатор, да и бэкап будет (если subversion сервер навернется — история пропадет, в чекауте она не хранится).
— (редко, но) муторно заводить новый репозиотрий в svn, в то время как «git init» делается где/когда угодно, и позволяет работать локально столько долго сколько потребуется, и потом «централизировать» тоже за пару команд (ну и создания новой репы на битбакете)
1. У меня нормальная сеть везде. Мне не приходится ждать. Или, как минимум, мне не надо комиттить изменение каждой буквы, как только она написана.
2. Не костыль разве в создании алиасов? Как минимум, лишние действия. Зачем мне локальный репозиторий-то, если я могу работать то с одной машины, то с другой? С сохранением истории правок за некоторое последнее время для меня сохраняет редактор сам.
3. Есть точно такие же сервера SVN. Как бес-, так и платные. Я пользуюсь приватным и бесплатным. Мало того, я еще и считаю его стабильным.
Если сервер упадет, у меня есть полная последняя версия на одной из машин. И, если я работаю действительно один, я считаю, что переживу крах истории. Все же проект прогрессирует, а не топчется на месте.
4. Есть визуальные средства, где я все делаю за два клика. И в гит, и в SVN. Почему-то не муторно.
Для определенных задач нужно использовать определенных инструменты.
Если Ваш инструмент универсальнее и моднее, это не значит, что он лучше для конкретных задач. И к черту универсальность, если она требует от меня дополнительных действий или заставляет запоминать какую задачу и на каком месте я ее решил.
2. Не костыль разве в создании алиасов? Как минимум, лишние действия. Зачем мне локальный репозиторий-то, если я могу работать то с одной машины, то с другой? С сохранением истории правок за некоторое последнее время для меня сохраняет редактор сам.
3. Есть точно такие же сервера SVN. Как бес-, так и платные. Я пользуюсь приватным и бесплатным. Мало того, я еще и считаю его стабильным.
Если сервер упадет, у меня есть полная последняя версия на одной из машин. И, если я работаю действительно один, я считаю, что переживу крах истории. Все же проект прогрессирует, а не топчется на месте.
4. Есть визуальные средства, где я все делаю за два клика. И в гит, и в SVN. Почему-то не муторно.
Для определенных задач нужно использовать определенных инструменты.
Если Ваш инструмент универсальнее и моднее, это не значит, что он лучше для конкретных задач. И к черту универсальность, если она требует от меня дополнительных действий или заставляет запоминать какую задачу и на каком месте я ее решил.
2. Вообще как в git, так и в mercurial можно настроить хуки, которые отправят изменения сразу после их фиксации. И запретят фиксацию, если в центральном репозитории есть новые изменения. В отличие от псевдонимов, будет работать и в gui. Bazaar так вообще поддерживает такой режим «из коробки».
3. Никогда не видел чужих серверов, которые бы не подтормаживали в сравнении с mercurial. Правда это дело привычки — когда команда начинает работать быстрее старая версия начинает заметно тормозить, хотя на самом деле исполняется с той же скоростью.
У меня тоже проекты по большей части развиваются одним мной, но тем не менее мне зачастую нужны ветки для экспериментального кода. Работа с такими вещами в svn, по моему мнению, весьма неудобна.
Subversion создаёт слишком много точек отказа: для работы помимо самого компьютера нужны ещё как минимум сеть (как минимум две точки — от клиента и от сервера, то, что посередине обычно весьма надёжно) и сам сервер.
Кроме того, правка описания изменения неудобна и требует включения некоторых возможностей на стороне сервера, а как быть, если мне нужно поправить само изменение (что‐то забыл включить в коммит или включил что‐то не то) я не представляю (правда если использовать предложенные в п.2 хуки то в git/mercurial обе операции станут ещё более неудобными, а в mercurial на чужом сервере — вообще невозможной без полного удаления репозитория; что с bazaar — не знаю).
3. Никогда не видел чужих серверов, которые бы не подтормаживали в сравнении с mercurial. Правда это дело привычки — когда команда начинает работать быстрее старая версия начинает заметно тормозить, хотя на самом деле исполняется с той же скоростью.
У меня тоже проекты по большей части развиваются одним мной, но тем не менее мне зачастую нужны ветки для экспериментального кода. Работа с такими вещами в svn, по моему мнению, весьма неудобна.
Subversion создаёт слишком много точек отказа: для работы помимо самого компьютера нужны ещё как минимум сеть (как минимум две точки — от клиента и от сервера, то, что посередине обычно весьма надёжно) и сам сервер.
Кроме того, правка описания изменения неудобна и требует включения некоторых возможностей на стороне сервера, а как быть, если мне нужно поправить само изменение (что‐то забыл включить в коммит или включил что‐то не то) я не представляю (правда если использовать предложенные в п.2 хуки то в git/mercurial обе операции станут ещё более неудобными, а в mercurial на чужом сервере — вообще невозможной без полного удаления репозитория; что с bazaar — не знаю).
Локальный репозиторий даёт возможность поэкспериментировать, а потом отправить в центральный только один результирующий коммит без следов неудачных экспериментов.
НЛО прилетело и опубликовало эту надпись здесь
На работе перфорс, на халтурах — git и hg. Но чаще hg.
Повторю слова одного Человека, с большой буквы, который презентовал гит на конференции у гугла в 2007- «Если вы используете svn то ваше место не здесь а в психушке». Прошло почти 5 лет и ie и svn остаются популярными, куда катится этот мир…
количество людей, использующих svn, немного пугает
Оно надежное, процессы отлажены, скрипты написаны, сотрудники обучены.
Единственный реальный недостаток — нельзя сделать кучку мелких коммитов локально и потом отгрузить в общий репозиторий. В остальном вполне юзабельно для коммерческой разработки в рамках офиса — доступ к репозиторию у всех есть, сетка быстрая.
Единственный реальный недостаток — нельзя сделать кучку мелких коммитов локально и потом отгрузить в общий репозиторий. В остальном вполне юзабельно для коммерческой разработки в рамках офиса — доступ к репозиторию у всех есть, сетка быстрая.
За время, которое уходит на merge в svn и синхронизацию работы команды, можно вполне себе освоить git или mercurial
Не понял.
Я наивно полагаю, что довольно неплохо владею всеми тремя популярными VCS: SVN, GIT, Mercurial. И merge во всех трех выглядит абсолютно одинаково.
1. В какой ситуации merge в svn занимает больше времени, нежели в mercurial или git? Про ситуацию, когда папку долго переименовывали, двигали по репозиторию и параллельно коммитили в ее файлы просьба не рассказывать — во-первых, это случается раз в пятилетку, а во-вторых и git, и mercurial в ситуациях, отличных от детсадовских будут точно так же давать merge конфликты с необходимостью ручного руления.
2. Чем «синхронизация работы команды» в случае SVN медленнее, чем при использовании GIT и Mercurial? В компании, где я сейчас руковожу отделом используется SVN. В другой организации, где я консультирую, используется mercurial. За последние года два я не заметил, чтобы система контроля версий хоть как-то влияла на «синхронизацию команды». К системе управления задачами у меня не порядок больше вопросов. А коммитят что там, что тут одинаково.
Я наивно полагаю, что довольно неплохо владею всеми тремя популярными VCS: SVN, GIT, Mercurial. И merge во всех трех выглядит абсолютно одинаково.
1. В какой ситуации merge в svn занимает больше времени, нежели в mercurial или git? Про ситуацию, когда папку долго переименовывали, двигали по репозиторию и параллельно коммитили в ее файлы просьба не рассказывать — во-первых, это случается раз в пятилетку, а во-вторых и git, и mercurial в ситуациях, отличных от детсадовских будут точно так же давать merge конфликты с необходимостью ручного руления.
2. Чем «синхронизация работы команды» в случае SVN медленнее, чем при использовании GIT и Mercurial? В компании, где я сейчас руковожу отделом используется SVN. В другой организации, где я консультирую, используется mercurial. За последние года два я не заметил, чтобы система контроля версий хоть как-то влияла на «синхронизацию команды». К системе управления задачами у меня не порядок больше вопросов. А коммитят что там, что тут одинаково.
Я сейчас с периодичностью 2-3 раза в неделю делаю merge из одной долгоживущей ветки в другую долгоживущую ветку (release A => active), ветки понемного расходятся. С учётом разрешения merge-конфликтов на это уходит около 2-5 минут на update + merge + push. Используем git, подозреваю, что c svn всё было не так радужно.
Не понял.
Почему в svn это занимало бы больше времени, чем в git? Я тоже использую долгоживущие ветки и синхронизирую их между собой. Никаких кейсов, в которых у git было бы преимущество, я не замечал. Можете привести конкретные пример? Может, я что-то не учитываю, раз все говорят что в svn merg очень тяжело делать, а в git легко?
Почему в svn это занимало бы больше времени, чем в git? Я тоже использую долгоживущие ветки и синхронизирую их между собой. Никаких кейсов, в которых у git было бы преимущество, я не замечал. Можете привести конкретные пример? Может, я что-то не учитываю, раз все говорят что в svn merg очень тяжело делать, а в git легко?
Ну это не городская легенда, объяснялось уже много раз, например:
stackoverflow.com/questions/2475831/merging-hg-git-vs-svn
Вкратце: головняк если какие-то файлы были переименованы, а также когда сценарии мерджей выходят за рамки простых отпочковал -> накоммитил -> смерджил назад.
stackoverflow.com/questions/2475831/merging-hg-git-vs-svn
Вкратце: головняк если какие-то файлы были переименованы, а также когда сценарии мерджей выходят за рамки простых отпочковал -> накоммитил -> смерджил назад.
Про конфликты переименований с коммитами я уже писал — да, есть такая проблема, но на практике это не то чтобы очень часто происходит. А у вас как? Часто файлы переименовываются и коммитятся одновременно и конфликтно?
Ну у нас последний раз не то что мердж, а switch тормозил. Совсем некомфортно было использовать ветки.
Если не секрет, часто switch делали? Это на практике для чего используется?
Позволю себе ответить за автора — для работы одновременно в нескольких бранчах, вестимо.
Что мешает сделать checkout каждую бранч в свою физическую папку и иметь несколько папок с бранчами без необходимости делать switch? switch — процесс в любом случае небыстрый, так как он меняет количество и содержимео файлов. Да, в случае subversion изменения передаются по сети, а в случае git / mercurial они считываются из локального репозитория — но что мешает один раз это сделать и пользоваться папками?
В случае, когда все изменения кода имеются локально:
1. Не нужны хосты под каждую из папок, не нужно запоминать на каком хосте какая из веток.
2. Гораздо происходит процесс мерджа между ветками — то есть при свежих изменениях в мастере их гораздо проще влить в рабочую ветку тут же, без участия удаленного сервера.
1. Не нужны хосты под каждую из папок, не нужно запоминать на каком хосте какая из веток.
2. Гораздо происходит процесс мерджа между ветками — то есть при свежих изменениях в мастере их гораздо проще влить в рабочую ветку тут же, без участия удаленного сервера.
Использую и SVN и Git 50 на 50.
В своих — Hg, на работе — гит. Голосовал за гит.
Пару месяцев назад форсированно перевел все рабочие репозитории на git и в паре с gitolite с его правами доступа наступило счастье :)
Tortoise SVN
Не хватает варианта «Я копирую всё на дискеты раз в месяц» :)
Мне кроме Git ещё нравится Fossil.
На работе свн.
Активно всех форсирую переходить на гит. У нас даже какие-то курсы для своих была идея сделать. Осталось воплотить…
Активно всех форсирую переходить на гит. У нас даже какие-то курсы для своих была идея сделать. Осталось воплотить…
Работы для гладкого перехода может быть много.
— У нас хватило пары презентаций/демонстраций
— Важнее, то при переходе была пара человек, к которым все могли обратиться за помощью
— Очень важно наладить инфраструктуру (gitolite/..., ssh, бекапы).
— Стоит дать рекомендации по использованию UI клиента (не нужно посылать всех в командную строку): например, git extensions, у нас в демонстрациях не было командной строки — кому нужно это освоит позже.
— Было важно поработать с людьми/командами, и убедить их, что они смогут эффективно работать — у всех немного разные workflow.
В итоге мы успешно извели зоопарк из StarTeam, cvs, subversion, ClearCase => git.
Удачи!
— У нас хватило пары презентаций/демонстраций
— Важнее, то при переходе была пара человек, к которым все могли обратиться за помощью
— Очень важно наладить инфраструктуру (gitolite/..., ssh, бекапы).
— Стоит дать рекомендации по использованию UI клиента (не нужно посылать всех в командную строку): например, git extensions, у нас в демонстрациях не было командной строки — кому нужно это освоит позже.
— Было важно поработать с людьми/командами, и убедить их, что они смогут эффективно работать — у всех немного разные workflow.
В итоге мы успешно извели зоопарк из StarTeam, cvs, subversion, ClearCase => git.
Удачи!
НЛО прилетело и опубликовало эту надпись здесь
Чем, на ваш взгляд, он лучше, чем гит?
Нельзя сказать, что оно лучше гит. Есть некоторые вещи более удобные в гит, которым я пользуюсь, т.к принимаю участие в одном oss проекте, есть более неудобные.
Darcs использую для Haskell проектов, т.к он тесно с ним связан и там другой механизм версионирования — управление патчами. Вот есть товарищ, который рассуждает на эти темы, если интересно mark.stosberg.com/blog/darcs/
darcs.net/DifferencesFromOtherDVCS и описание с офсайта.
Darcs использую для Haskell проектов, т.к он тесно с ним связан и там другой механизм версионирования — управление патчами. Вот есть товарищ, который рассуждает на эти темы, если интересно mark.stosberg.com/blog/darcs/
darcs.net/DifferencesFromOtherDVCS и описание с офсайта.
На работе SVN. А дома я не работаю, у меня только браузер и игрульки =)
НЛО прилетело и опубликовало эту надпись здесь
Когда стоял выбор VCS для внедрения на предприятии, выбирал между Git и Svn. Сам склонялся к первому, но так как команда разработчиков никогда прежде не работала с системами контроля версий, а обучать их не было времени, то пришлось использовать svn.
Спасибо гитхабу за это
Использую TFS+Bazaar (в партизанском режиме) на работе.
Дома использую SVN для документов, а заодно и для своих проектов — сложилось исторически, лень пока менять.
Последний месяц тестирую fossil, но не в режиме работы с кодом, а как распределённую wiki для личных нужд.
Дома использую SVN для документов, а заодно и для своих проектов — сложилось исторически, лень пока менять.
Последний месяц тестирую fossil, но не в режиме работы с кодом, а как распределённую wiki для личных нужд.
На работе использую корпоративный SVN-репозиторий через мост `git svn`. Вполне сносно работает в обе стороны.
Везде, где можно — Hg.
Git популярнее, поэтому приходится сталкиваться и с ним; Hg-Git, к сожалению, иногда сбоит.
Git популярнее, поэтому приходится сталкиваться и с ним; Hg-Git, к сожалению, иногда сбоит.
Заглянул в Ваш профиль, увидел ссылку, кликнул, понеслась… Вы умеете себя презентовать. Может напишите топик со своим мнением о том как надо себя презентовать современному разработчику?
ЗЫ: Может кто-то как и я лазит по чужим анкетам и смотрит в инфо хабраюзерах. Мне кажется этот чел должен поделиться знаниями. Или я не прав? )
ЗЫ: Может кто-то как и я лазит по чужим анкетам и смотрит в инфо хабраюзерах. Мне кажется этот чел должен поделиться знаниями. Или я не прав? )
Для себя — Hg.
На работе — Hg.
В остальных случаях — Hg.
На работе — Hg.
В остальных случаях — Hg.
Не использую. После релиза дублирую папку с проектом и приписываю в конец номер версии :)
Только хародкор?
Или forever alone.
Мне тут КО подсказывает, что DVCS для одиночек ничуть не хуже работает, чем для групп. :) И уж точно намного лучше, чем вручную папки копировать. У меня самого своих одиночных фрилансерских проектов куча, тем не менее для всех я использую hg с бекапом в облако (bitbucket). А сделать commit или даже commit+push по любому быстрее, удобнее и надежнее, чем в ручную двигать файлы туды-сюды.
Ваш пост огорчает верующих. Сейчас словите минусов.
Те люди из принципиальных соображений или из технической неграмотности/консерватизма не пользуются нормальными инструментами усложняя жизнь себе и коллегам — они «нормальные», а те кто предпочитают профессиональный подход к профессии — религиозные фанатики?
Мне бы, кстати, было интересно услышать хоть один аргумент о преимуществе неиспользования SCM в работе программиста.
Мне бы, кстати, было интересно услышать хоть один аргумент о преимуществе неиспользования SCM в работе программиста.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Какую систему управления версиями вы используете? (в реальной работе, больше всего)